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Preventing DoS Attacks with A New 
Client Puzzle Scheme 

Yi Gao, Yi Mu, Willy Susilo 

School of Information Technology and Computer Science 
University of Wollongong, Australia 
{yg70, ymu, wsusilo}@uow.edu.au 

Abstract 

Denial of service (DoS) and distributed denial of service (DDoS) are serious threats to computer networks. 
One promising countermeasure against DoS attacks is the methods of Client Puzzle [4, 14]. However, the 
existing puzzle schemes are incapable of satisfying the high demand of DoS/DDoS defence. In this paper, 
we propose a new trapdoor-based client puzzle scheme to overcome most of the underlying drawbacks of 
the traditional ones. Our trapdoor-based client puzzle is provably secure under the RSA Assumption. 


Introduction 

With the booming of e-commerce and e-business through the Internet, service availability has become 
one of the most important principles of network security nowadays. “Availability” in this context refers 
to a service that can be accessed within a reasonable amount of waiting time after a legitimate client 
sends a request. DoS attacks via the Internet aim at shutting down a target server (service provider) and 
destructing its service availability. 

In general, DoS attacks attempt to block or degrade a service in a designated period temporarily, rather 
than intrude on the server directly or damage the data permanently. One of the most popular DoS attacks, 
TCP SYN flooding attacks, was first reported by several major newspapers in 1996 [1, 2, 12, 27], In such an 
attack scenario, a SYN flooding attacker exploits spoofed IP addresses to mount a large number of initial 
and unresolved connection requests to a victim server, depleting its resources and rendering it incapable 
of responding to legitimate clients. 

Distributed Denial of Service (DDoS) was rapidly brought to the public’s attention after eBay, Amazon, 
Yahoo and several other prominent commercial websites fell victim to this new form of DoS attacks on 
February 9th, 2000 [10, 26]. Relying on the fast spread of Internet worms [9], a DDoS attacker is able to 
easily manipulate thousands of vulnerable computers in the Internet to launch a large-scale DoS attack to 
a target. Compared with traditional ones, the strength of DDoS attacks can be multiplied by 10, 100, or 
even 1000, and the effect on the Internet is therefore immeasurable. 

A typical DDoS attack process can be described as follows. An attacker first scans a large range of 
networks to find vulnerable hosts that have weak defences against a malicious intrusion. The number of 
these hosts is determined by the strength of the attack that an attacker intends to launch. Second, the 
attacker installs “Master” or “Agent” programs on these vulnerable hosts. A machine with an “Agent” 
program is called a Zombie , which carries out the actual attack. A machine installed with a “Master” 
program is able to communicate with a number of “Zombies” and serves as a control-handler of the attacker. 
An attacker can command several “Masters” directly, and “Zombies” are activated by these “Masters” at 
the designated time for an attack. Fig (1) shows this three-layer control. The reason for using such 
an architecture is to keep the attacker safe and difficult to trace. Now, all the preparation has been 
accomplished. The attacker only needs to cross his fingers and wait for an appropriate time to launch his 
DDoS attack. When a defending server suspects that it is under a DoS attack, it can only find numerous 
legitimate connection requests received from a large number of legitimate IP addresses, consuming all the 
resources of the server. However, the real owners of these “Zombies” are unwitting accomplices [15], and 
do not know what has actually happened on their machines. 
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Figure 1: Three-layer Control For A DDoS Attack 


To protect against DoS and DDoS attacks, several approaches have been proposed in the literature 
[15, 14, 19, 18], among which Client Puzzle is one of the most notable and influential. Earlier work 
[6, 4, 14] showed that the client puzzle mechanism is capable of alleviating or confining DoS attacks to a 
harmless level in theory. 

The idea of client puzzle is very simple. When no DoS attack threat occurs, a defending server accepts 
and responds connection requests as normal. While the server suspects that it is under an attack, it 
sends a small cryptographic puzzle to every client who is applying for a service, before allocating any 
system resource to them. Only the request belonging to the client who solves the puzzle correctly will 
proceed. The cost for computing puzzles is trivial for legitimate clients, but unbearably expensive for a 
malicious attacker who attempts to seize considerable resources from the server. The aim of client puzzles 
is to destroy DoS attacks by forcing every suspected adversary to consume a number of computational 
resources for authentication, before he/she is granted access to the resources of a server. In contrast to 
traditional authentications (such as RSA, DSS), client puzzles seem weak, yet are inexpensive and efficient 
in determining whether a connection request is sent by network worms [9, 24]. 

A client who requests for a service from a defending server has to install a small client-side program 
for the computation of puzzles. In today’s network technology, such software can easily be implemented 
by a plug-in of a web browser, or distributed by network servers. Hence, the requirement for this special 
software should not be a problem. 


Related work 

The idea of Client Puzzle was first introduced as an access control mechanism by Dwork and Naor in 1992 
[13]. They proposed a system for junk mail defence, in which every successful delivery of a message requires 
the sender to solve a small cryptographic puzzle. By doing so, they successfully impose a large amount of 
computational costs on sending mass mails, while for legitimate clients, the costs to compute single puzzles 
are negligible. 

Combining the idea of a stateless protocol [3] and Client Puzzle, Juels and Brainard [14] proposed a 
Client Puzzle Protocol to protect network servers against SYN flooding attacks. This protocol emphasises 
that no memory should be allocated before client authentication, and that the client is the one who pays 
for the authentication. In their paper, Juels and Brainard also presented a simple puzzle construction to 
implement their protocol, although this seemed unsatisfactory and caused a lot of arguments in network 
forums [11, 21, 25]. 

Following this, a few researchers attempted to improve puzzle construction within the framework of the 
Client Puzzle Protocol. Aura and Nikander [4] proposed a hash function based puzzle scheme, in which a 
client needs a brute-force search for the correct answer, and a server performs a hash function to verify 
the solution. Waters and Juels [5] suggested a new technique that permits the outsourcing of puzzles to 
eliminate puzzle construction as a target of DoS attacks. 
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The problems 

By investigating the existing puzzle schemes, we note that most of them inevitably have several shortcom¬ 
ings. 

First, the complexity of puzzle construction and verification might turn the client puzzle mechanism 
itself into a victim of DoS attacks. For instance, client puzzles based on hash functions [4] require a 
defending server to calculate a hash function in order to verify each answer received from clients. As a 
result, an attack scenario may occur in which an adversary sends numerous bogus answers that the server 
has to process. Another more extreme example is where a Diffie-Hellman based construction [5] requires the 
server to perform a modular exponentiation for the solution of a puzzle, which consumes more resources 
than hashing does. It is clear that the cost of verification (for a defending server), being greater than 
that of generating random answers (for an adversary), may result in DoS attacks. On the other hand, 
a complicated construction also attracts attackers’ attention. A scenario of this type of attacks would 
be where, by utilising spoofed IP addresses, an adversary floods a defending server with false connection 
requests to cheat the server exhausting resources for puzzles’ construction. 

The second noticeable weakness in current schemes is that, to ensure the randomness and non-iteration 
of client puzzles, the defending server has to store all the correctly solved instances so that the solutions 
cannot be reused by attackers [4, 14], However, as time goes by, the memory space becomes congested. 
Meanwhile, to guarantee the validity of puzzles and solutions, the defending server has to perform two com¬ 
parisons respectively in puzzle construction and verification to examine whether the puzzles and solutions 
have been used before. This is undesirable in a client puzzle mechanism. 

Our contribution 

We propose a novel trapdoor-based client puzzle scheme, which has two distinct features: the computational 
overheads are low, and the difficulty level of puzzles can be measurable. We will prove in the full paper 
that this scheme is provably secure under the RSA Assumption [22]. We will demonstrate how a trapdoor 
puzzle can be generated by a defending server, and how a client achieves the correct answer. By counting 
their respective workloads, the advantages of our scheme will be analysed in contrast with other proposed 
schemes. 


Organisation of This Paper 

The rest of the paper is organised as follows. In Section 3, we provide the preliminary knowledge as to the 
RSA Assumption. A formal definition of a trapdoor-based client puzzle scheme follows in Section 4. After 
that, we describe the details of the RSA Assumption-based puzzle scheme, which consist of a trapdoor 
a gorithm, system description, security considerations and remarks in Section 5. Finally, we include this 
paper in Section 6. 


Preliminary 

The factorisation problem is a problem used to calculate a series of prime integers from a given number. 
In current cryptosystems, people particularly focus on factoring an integer N which is the product of two 

arge primes p and q. This problem has been studied by many researchers, and even now, it still cannot 
be solved efficiently. 

The RSA Assumption is derived from the hardness of factorisation problem, which was first introduced 
by R’vest and Shamir in [22], They claimed that it is infeasible to compute e-root in the group of order 

n N ) (p 1 )(q 1), where e e Z* (Af) is relatively prime to <t>(N). That is given N, e, and a random 

element j g 7 * u — 1 *•--* ’ ■’ - - -- 

follows. 


U N ’ 


’ \ / \ / - o -“ ' J J a XlUVill 

it is hard to compute x such that x e = y (mod N). More formally, we define it as 


Assumption 1 The RSA Assumption holds, if for all probabilistic polynomial time adversaries A the 
joiiowing probability 

N <-RSA{p,q) ; 

P r e ^4>(N) 1 y '■ < £ 

A(N, y,e) = x s.t. x e = y (mod N) 

As a matter of fact, computing e-root in Z* N is equivalent to solving the factorisation problem. Assume 
that a polynomial adversary A is able to factorise N into two large primes p and q efficiently. He can then 
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compute (j>{N) — (p — l)(g — 1), and exploit the extended Euclidean algorithm [7] to obtain d such that 

e ■ d= 1 (mod 4>{N)) 

That is 

d = e -1 (mod 0(1V)). 

Now, he can obtain x = y d (mod N) by taking the modular exponentiation instead of the e-root compu¬ 
tation. 

Hence, we believe that if the factorisation problem is hard in polynomial time, the RSA Assumption 
holds. However, if people can find an efficient way to solve the factorisation problem in the future, the 
RSA Assumption will not be valid any more. 

Another confusing problem which should be noted is that the security of the RSA scheme 1 does not 
depend totally on the factorisation problem. This means that an attacker may break the implementation 
of the RSA without the operation of factoring N. Some of these types of attacks have been reported in |23] 
and [8], such as “Chosen Ciphertext Attack”, “Common Modulus Attack”, “Low Encryption Exponent 
Attack”, etc. 


Definition 


The aim of a trapdoor-based client puzzle scheme is to protect service availability transferred between a 
defending server S and legitimate clients C against DoS attacks. The scheme exploits a specific trapdoor 
one-way function, where a creator of puzzles (the server S) can efficiently compute the correct solution, 
while other solvers (legitimate clients C and an adversary A) must perform a brute-force search to obtain 
the answers. The scheme consists of three efficient algorithms for generating random puzzles, solving the 
puzzles and verifying the solutions of these puzzles, respectively. 

Definition 1 A trapdoor-based client puzzle scheme consists of a three-tuple of polynomial algorithms 
{Gen, Solve, Verify), where 

• Gen : Puzzle generation algorithm used by a defending server S . It takes security parameter t and 
a difficulty level / as input, and outputs a random puzzle V along with a correct solution S s to the 
puzzle V . That is 

C P,Ss) «- Gen(lM). 

Indeed, a puzzle V comprises two elements denoted a s V = {a,[a,/3}) where a is a puzzle parameter, 
and [a, (3] is a search range of length l. That is l = \/3 — a|. 

• Solve : Puzzle-solving algorithm. This is an efficient algorithm for a client C to solve the puzzles. 
On input V = (cr, [a,/?]), it computes an answer S c . 

S c <— Solve(7 ? ) 


• Verify : A deterministic algorithm performed by 5. On input S s and S c , it outputs either one or 
zero. 

Verify {S s ,S c ) e {1,0} 


Success: Define the success of a client solving a puzzle by: 

Verify {S s ,S c ) = 1, if S s = S c holds. 

Correctness: We require that all the answers that are computed correctly by Solve(-), will always pass 
the verification. That is 


Pr 


{V,Ss) <— Gen(l fc ,l); 
S c «- Solve('P) : 

1 <— Verify (S s ,S c ) 


1 


Semantic Security: For every probabilistic polynomial time adversary A, the probability of finding 
another efficient algorithm to compute a puzzle’s solution, rather than performing a brute-force search in 
the given range [a, /?], is negligible. 

iThe RSA scheme can provide encryption and signature functions [16], which is a different notion from the RSA Assump- 
tion. 
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Pr 


Solve(-) ^ Solve(-) ; 
S~ c «- SolpP ) : 

1 «- Verify ( S s , S c ) 


< £ 


Collision resistance: The probability of the existence of two uniform integers S c and S' c in the search 
range [a, /?] is negligible. 


Pr 


S c <— Solve( V ) ; 
S' c e[a,S} ■ S' C = S C : 
1 Verify ( S s , S' c ) 


< £ 


Theoretically, there is only one correct answer for the puzzle in the range [a,/?], which ensures that only 
the client who accurately complies with the description of the puzzle to perform the searching and the 
computation can obtain the right solution. 


Information Theoretic Secrecy: A puzzle solution S c does not reveal any information about either 
possible puzzle constructions or other secrets of a defending server. 



Vi = ( Oi, [Qi,/?i] ) ; 

S Ci <— Solve(7 ? i ) : 
{ a i+l \ Qi+i| 0i+ 1 } <— S Ci 


< £ 


The RSA Assumption-based Puzzle Scheme 

This novel puzzle scheme is based an efficient trapdoor algorithm whose security relies on the RSA As¬ 
sumption. Now, we start with the introduction of this trapdoor algorithm in the following section. 


Algorithm 

L f N * e th f product of two large primes p and q. Maintain p and q as secrets. It is computationally 
mleasible to factorise N for all polynomial adversaries. Denote cf>(N) = (p — \){q — 1 ). Let e 6 Z* be a 
prime such that GCD(e, 4>{N)) = 1. g is a random integer in the group of order 

Puzzles constructed in this RSA Assumption-based scheme are derived from the following equation: 

M = g a -r e (mod N) ^ 

where « e [l,e - 1 ], random re Z* N . Given a value of M , we find that for each a! £ a, there exists a 
unique r’ such that M = g a ■ (r') e (mod N) holds. We present it as follows. 


M — g a ■ r e = g a ■ (r') e (mod N ) 


( 2 ) 


Indeed, for each a', the value of r' is equal to the e-root of M ■ g~ a ‘ 
The trapdoor of this algorithm is the value of x = gi (mod N). 
follows. 


(mod N). 

In this case, we plug x in Eq (1) as 


M — g a ■ r e (mod N) 

= (x e ) a ■ r e (mod N) 

= ( x a ■ r) e (mod N) ^ 

Let y = x a ■ r, then we show that y equals the e-root of M. 

y = M<= = x a ■ r (mod A^) ( 4 ) 

Note that if M is kept constant, y is uniformly a constant which inherits the same property as in Eq 
(2). Given a value of y, for each a ^ a', there exists a unique r’ such that 


y = x a ■ r (mod N) 
= x a ~ a ■ r' (mod N ) 


( 5 ) 



8 


PREVENTING DOS ATTACKS WITH A NEW CLIENT PUZZLE SCHEME 


Now, we can compute 


r = (y ■ x a ) ■ a (mod N) ( 6 ) 

Our scheme is such that, given a pair (a, r), the puzzle creator obtains the values of M and y (= 
M « mod N). Keeping them constant, the creator varies the value of a' for each new puzzle, and meanwhile, 
computes r' by using Eq ( 6 ). Due to lack of knowledge about x, y, the solvers have to conduct three steps 
ruled by the creator as follows, to obtain the answer r'. 

(i) Receive the values of M, g a , e, N and a search range for r' from the creator. 

(ii) Pick up a candidate r' from the range and test whether M = g a ■ (r') e mod Ah 

(iii) Repeat (ii) until all possible r' are tested or a r' that satisfies Eq (1) is found. 

In this puzzle scheme, the computational cost consumed by the creator is quite distinct from that 
consumed by solvers. For the creator, it merely needs one modular multiplication r' — T ■ a' (mod N) 
to solve a puzzle, because y ■ x~ a can be pre-computed and referred to as a constant T. A solver, on the 
other hand, has to perform a brute-force search and a number of modular exponentiations to determine 
the answer. Furthermore, the creator is able to control the computational cost consumed by the solvers by 
adjusting the length of the search ranges. 

System Description 

In this section, we shall present how a system using the above puzzle scheme works for DoS defence. The 
system begins with a regular examination of the defending server to determine whether it is currently under 
a DoS attack. A standard parameter for an attack check can be the status of buffer space consumed or 
the number of TCP connections. If the parameter is under the standard value, it means there is no DoS 
attack threat. Otherwise, the server starts up the client puzzle mechanism. 

We divide the defence scheme into four phases, which are the preconstruction phase, the construction 
phase, the puzzle-solving phase and the verification phase, respectively. Apart from the puzzle solving, 
which is performed on the client’s side, these phases all run on the server. 

1. Pre-construction phase 

An analysis of the trapdoor algorithm outlined above indicates that the puzzle creator (S) needs a 
number of constants to generate puzzles. Thus, to decrease computational overheads and improve 
efficiency in the construction phase, we introduce pre-computation into our scheme. 

The pre-construction procedure is illustrated as follows: 

(i) Determine a time interval T d , and the size of set A denoted by n. 

There is a trade-off between Td and n, which requires some careful thought. In fact, the server 
needs to find the minimum n and the maximum T d that satisfy the following requirement: n 
is minimum greater than the maximum connection ability of the server in each time period. It 
guarantees that in the same time period no element in set A can be selected more than once. 
For instance, if the hourly maximum connectivity of the server is 50,000 on average, n should 
be from 50,001 with T d = 1 ■ 

(ii) Establish A. 

Variable a' for each new puzzle (M = g a ' ■ ( r') e modiV) is derived from A. First of all, the 
server creates a superincreasing sequence / [23] such that 

i'-l 

I = { bi\ 1 < i < m,m > n, 6 ; G [l,e — 1] } fl { V 6 i,b' G I\ ^ bi < 6 ' } 

i= 1 

This means that every item belonging to I is greater than the sum of all the previous elements. 
For example, {3, 7, 13, 29, 67} might be a subset of I, while {3, 5, 7, 11} is not. 

To build A, the server randomly picks up n(< m) non-repeated elements from I. Then, we can 
obtain A such that 


X 

A = {a s | 1 < i < n, a, € I } n {Vai, a- G A, 1 < x < n\ a' ^ ^ a. } 

i= 1 
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Recalling the property of a superincreasing sequence I, we know that every instance in A cannot 
be equal to the sum of any arbitrary instances. Fig (2) illustrates this property more clearly. 
Assume that {1, 3, 5, 11, 23} is a subset of superincreasing sequence I. To set up A, the server 
chooses four non-repeatable elements from I randomly. Then, we obtain A = {3,11,1,5}. Note 
that we cannot obtain any element in A by summing up any other discretionary number of 
elements. For example, 11 + 1^3 + 5, 11^3 + 5 + 1,3 + 1/5, and so on. 


li 
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(2) 11 +1 >5 + 3 



(4) 5 > 3 + 1 


Figure 2: A Sample of Set A 


(iii) Compute Ga, which is a multiplier factor for constructing a puzzle. 

G a = {g a ‘( modA0|l < i < n,in e A}n{Vo;,a' € A,a { ± a'| g a ‘ ± g<} 

(iv) Compute X A , which is a multiplier factor for solving a puzzle. 

X A = {x a< (mod N )| 1 < i < n,a t € A} 

(v) Generate and encrypt the time parameter t. 

The form of t is defined as: 

{ yymmddhh l hh 2 } fl {hh 2 - hh 1 = T d } 

For instance, when the server selects the time interval T d = 2, a time parameter for 17:00 to 
19:00 on January 9th, 2005 is t = 0501091917. Then, encrypt t by computing g l ( mod N) and 
x L ( mod N), respectively. Note that g l and x l are unique in an identical T d , and computed 
before each new time period starts. 

(vi) Calculate M and T by Eq (1) and Eq (6) 

M = g a ■ r e (mod N) 

T = y ■ x~° = M d ■ x~ a (mod N) 

where a E [l,e — 1] and r €r T,* n are a pair of initial values. The server will publish the value 
of M as part of the description of puzzles, and keep T secret. 

After accomplishing the pre-construction, the server obtains a number of constants { M, T, A, Ga 

X A }, and two periodic constants {g l ,x 1 }. Note that except M is public, the rest are kept secret on 
the server. 

2. Construction phase 

When receiving a request from a client C, the server S generates a puzzle V = (g a ', [a, (3\) along 
with its correct solution r s . V is essential for a client solving a puzzle. r s is stored on the server for 
verification of the answer returned from the client. This stage is described as follows. 
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(i) Compute g a 

g a ' = g l ■ g a ' (mod N) (7) 

where g ai £ Ga, t is the current time period and g l is a periodic constant calculated at the 
beginning of t. The server picks up random g ai £ Ga to generate a fresh puzzle, then marks 
this g ai to be unavailable until a new period comes. This means that when each period starts, 
all the elements in Ga are available. An element is marked unavailable throughout the same 
period, once it is chosen by the server to create a puzzle. 

(ii) Generate r' 

x a = x l ■ x ai (mod N) ( 8 ) 

t\j = (y ■ x~ a ) ■ x a (mod AT) 

= T ■ x a (mod N) 

Note that the values of i in Eq (7) and Eq (9) are uniform. 

(iii) Obtain a search range [a, (3\ C TA N 

a = r s — c (mod N) 

P = a + 1 (mod N) 

for random c £ [0, Z), where l is the current difficulty level of the puzzles. 

3. Puzzle-solving phase 

Unlike the other three, this phase is performed on client’s side. We assume that a client C has 
installed a specific piece of software which is distributed by the server. It solves puzzles received from 
the server with an equation 

M = g a ■ r e (mod N) 

and a triple of constants (M, e, N), and an interface for accepting puzzles from the server. 

When a client receives a puzzle V, he employs an exhaustive search (brute-force) to find the answer 
r c which satisfies the equation. Due to the length of the search range l = p - a, a client C needs to 
perform 1/2 modular exponentiations to find the answer r c on average [5]. 

4. Verification phase 

Upon receiving the answer r c from a client, the server compares it with the stored solution r s that 
has been calculated in the construction phase. If they are equal, Verify (■) outputs 1, which means 
that authentication of the client is verified, and the server proceeds with the rest of the request. 
Otherwise, Verify (•) outputs 0, and the server drops the request. 

Verify (r 0 ,r c ) = | J Otherwise 
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Client 


public: M, e, N 


- Generate candidate data sets: 
A = {oi, a 2 ,..., a„} 

X A = {x ai ,x a2 ,...,x an j 

g a = {g ai , g a2 , ■ ■ ■, g an } 

- Generate g l , x l 

for the current time period 

- Generate constant: T 


Server 


M — g a -r e = g a ‘ ■ (r') e (mod N) 
x = <?= (mod TV) 
y = M-- = x a ■ r (mod TV) 
secret: x, g, y 


Pre-construct a puzzle: 


Construct a puzzle: 

g a ‘ t = g l ■ g a ' (mod TV) 
x a> = x l ■ x ai (mod TV) 
r s = T ■ x a ‘ (mod TV) 
random c £ [0, /) 

[r s - c,r s - c + l\ —> [a, f3\ - ' P=(g ° ’ |a ' m : 

Search for r c to meet: 
M = g a -r e (mod TV) 

Verify a solution: <_Es_ 

? 

r s = r c 


Allocate resources for a client 
or drop a request according to 
the correctness of the solution 


Proceed 


Figure 3: A RSA Assumption-based Puzzle Scheme 
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Security Considerations 

Theorem 1 If Eq (2) holds, then the solution r' computed by Eq (6) can be verified. 

Proof: Given the initial values of (a, r), we obtain the following result 

M = y e = ( x a ■ r) e = ( x e ) a r e = g a ■ r e = y e (mod N) 

To create a new puzzle, we choose a' and obtain the solution r‘ = (y ■ x~ a )x a . Then we verify it in Eq (2) 

M = y e = [x a ~ a ' • (r')] e = (x a - a ‘) e ■ (r') e (mod N) 

= (x a ~ a ') e ■ [{y ■ x~ a )x a '\ e (mod N) 

= (x e ) a ~ a ' ■ y e ■ (x a '~ a ) e (mod N) 

= g a ~ a> ■ y e • g a '~ a (mod N) 

= y e (mod N) 

Theorem 2 Under the RSA Assumption, our scheme is secure. 

Proof: Before presenting the proof, we firstly recall the RSA Assumption. N is the product of two large 
primes p and q. Given two elements e € Z* (JV) , g € Z* N ( where e is relatively prime to <f>(N) ), it is 
computationally infeasible to find a non-negative integer x such that 

x e = g (mod N) 

holds, which is equivalent to factoring pq [20]. 

We assume there is an algorithm A which can output a pair of ( a,r ) and (a',r'), where a y a! and 
r y r 1 , for given values of M, g, e € Z* N , such that 

M = g a ■ r e = g a ■ ( r') e (mod N) 

holds with a non-negligible probability. 

Now, we show that an algorithm B intends to use A to break down our scheme by computing the 
trapdoor x = g* (mod N), which is assumed to be secure under the RSA Assumption. This simulation 
is described as follows. 

After obtaining a pair of values (a,r) and (a,f), B transforms the following equation: 

M = g a ■ r e = g a ■ (r') e (mod N) 

and obtains , 

g a ~ a ' = C-) e (mod N) 

Let 0 = a — a!. Since a, a' < e and e is a prime, we note that GCD(0 , e) = 1. According to the extended 
Euclidean algorithm [7], we can find two integers m, n such that m9 + ne = 1. Now, B can obtain the 
following permutation by using the previous equation. 

g = g™ 6 +ne _ g ™0 . g ne ( mod jy) 

= (g e r-g ne (mod N) 

= [(-) 8 } m -g ne (mod N) 
r 

= [ (^) m ■ g n ] e (mod N) 

If B is able to take e-root computation in Z* N , he will obtain the trapdoor x, such that 

x = gi = (-) m ■ g n (mod N) 
r 

Note that the probability that A outputs a = a' and b = b' is equal to \/N 2 . Moreover, e-root 
computation in a cyclic group (order N) is computationally infeasible under the RSA Assumption. Hence 
the success probability of B is lower bounded by 1/N 2 . We have now completed the proof. 
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Remarks 

Theorem 3 This new puzzle scheme is qualified to a trapdoor-based client puzzle scheme. 

Proof. We need to show that the above scheme satisfies the requirements of the trapdoor-based client 
puzzle scheme as stated in Section 4. 

• Correctness. It is easy to verify that answers computed correctly in the puzzle-solving phase can 
always pass the final verification on the defending server. 

In the proposed scheme, we provide a search range \a, (3] which ensures the existence of the correct 
solution r s . Because 

[a, P\ - c, r s - c + l} for c € [0, l) 

where both c and l are positive integers, this means 

r s — c < r s < r s - c +1 

Hence, a client can eventually find a r c (= r s ) which makes Eq (1) valid, as long as he employs an 
exhaustive search. 

• Semantic Security. Due to the hardness of Factorisation (or the RSA Assumption), a more efficient 
way to obtain the correct answer than a brute-force search cannot be found. We will prove this claim 
in the Security Considerations section below. 

• Collision-resistance. According to the property presented in Eq (2), for each a 1 € [1,e — 1], there 
exists a unique value r 'ez* N which can satisfy the equation M = g a ■ ( r') e mod N. 

• Information Theoretic Secrecy. No client can pre-compute a puzzle by guessing or revealing the secret 
components of the server. 

— If a client knows the trapdoor x, he can solve all the puzzles created by this scheme efficiently. 
However, we have proved in Theorem 2 that the probability of this scenario is negligible under 
the RSA Assumption. 

- Puzzles generated by the server can be viewed as random. 

The server establishes a random and non-repeatable set A {A = {a*|1 < i < n, a, € [1, e — 
1|}) in the pre-construction phase. On the basis of A, the server calculates Ga (Ga = {g a ' 
(mod p) | 1 < i < n, ^ 6 4}) as a necessary parameter for creating puzzles. Note that the 
values of g a ' are irregular, and hence, the probability of guessing an instance in G a is 1/N. 
When N is large enough, we can say that this probability is negligible. 

This scheme also meets the essential requirements that we advocated in Chapter 4 for promising client 
puzzles. 

Remark 1 The computational resources consumed by a client to solve a puzzle are greater than those used 
by the server to generate the puzzle and verify the solution. 

A defending server performs three modular multiplications and two additions to create a puzzle and 
obtain the solution at the same time. 

To produce g a , the server performs one modular multiplication: 

9 a = g 1 ■ g ai (mod N) 

To obtain the solution, the server performs two modular multiplications: 

r' s = T x a = T ■ x l ■ x ai (mod TV) 

To generate the search range [a,/?], the server performs two additions: 

a = r' s — c ; /3 = a +1 

To verify a solution, the server only needs to make a comparison. 

? 

r s = r c 

To solve a puzzle, however, a client has to conduct on average 1/2 modular exponentiations and com¬ 
parisons, which consume much more computational resources than modular multiplications and modular 
additions [17], In addition, we ensure that the size of p and q are large enough to resist any attacks on 
factorisation. As a result, the answer can only be obtained by exhaustively searching the seed range and 
performing modular exponentiations until the correct instance that satisfies the public equation is found. 
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Remark 2 Our scheme is better than the Hash function [4] and Diffie-Heilman [5] based puzzle schemes. 

• The unique solution guarantees that the defending server can perform a simple comparison to verify 
puzzle solutions. This is more efficient and effective in protecting the verification phase against DoS 
attacks than the Hash function based puzzle scheme, in which the defending server is required to 
perform a hash function for solution verification. 

• To adjust the difficulty of a puzzle, we exploit a non-negative integer l to control the length of a 
search range. The value of l varies according to the strength of a DoS attack. When the strength of 
an attack degree is low, l is correspondingly small and the cost of solving a puzzle is insignificant for 
a client. If an attack worsens and l enlarges, a client has to supply more resources to find a solution. 
On average, it requires 1/2 modular exponentiations to solve a puzzle. Hence, our scheme is more 
easily measurable than the Hash function based puzzle scheme. 

• To avoid puzzle iteration, the Hash function based scheme requires that a record of the used instances 
is kept for a long time, and it performs two comparisons in puzzle construction and verification 
respectively. However, relying on the time parameter t , our scheme can always obtain unique puzzles 
without wasting memory space and computational time. The items calculated in the pre-construction 
phase can also be reused in every new time interval. 

• As well as relying on the outsourcing for puzzle construction, the Diffie-Hellman based puzzle scheme 
requires a modular exponentiation to obtain a correct solution. Note that a modular exponentiation 
can be divided into many modular multiplications [17] and a large number of modular additions. Our 
RSA Assumption-based scheme, on the other hand, only needs three modular multiplications and 
two additions to obtain a puzzle and its corresponding solution, which is more efficient. 

• Our scheme is resistant to eavesdropping attacks. As we claimed earlier, no puzzle construction infor¬ 
mation is revealed during communication between the defending server and its clients. In addition, 
each connection request has a unique solution, so that eavesdropping is rarely advantageous to an 
attacker. 

• By varying the values of public instances (such as M, e, N) and constant instances (such as A, 
Ga , Xa), distinct web servers can obtain different puzzle schemes. This is more flexible for current 
network servers that possess various capabilities. 

Through these remarks we conclude that our RSA Assumption-based puzzle scheme is qualified in 
theory. 


Conclusion 

In this paper, we have depicted a novel trapdoor-based client puzzle scheme. This scheme has two distinct 
features: the computational overheads are low, and the difficulty level of puzzles is measurable. We also 
presented that this scheme is provably secure under the RSA Assumption, and enables to work effectively 
and efficiently. 
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Abstract 

This paper describes the design and implementation of Cryptkit - a Tel extension providing a powerful 
toolkit that makes adding encryption and authentication services to Tel applications straightforward, even 
for inexperienced crypto programmers. Cryptkit contains an abstracted object-oriented binding to the 
Cryptlib security toolkit - a powerful, portable and comprehensive security library written in C. The 
paper will also discuss possible future developments, including a Tel stacked channel interface and an 
implementation of the recently endorsed X9.95 Trusted Time Stamp Management and Security standard. 


Introduction 

The genesis of Cryptkit came about during the 11th Tcl/Tk Conference[l] in New Orleans when Mike Doyle 
of Eolas Technologies commented that it should be possible to produce a Tel cryptographic extension based 
on Cryptlib [2]. His rationale was quite simple - it is trivially easy to build client/server and web applications 
m Tel so it should be just as simple to add appropriate security. And although there are a number of 
good cryptographic extensions for Tel (in particular TLS[3]) there is no single cryptographic toolkit that 
supports a wide range of cryptographic and authentication features. 

Mike asked this author if he would be interested in producing a Tel interface to Cryptlib. In one of 
his more optimistic pronouncements of recent times, this author responded “sure - I can probably throw 
together an interface quite quickly . Whist that was (strictly speaking) true, producing an appropriate 
interface turned out to be significantly more work, for a number of reasons: 

• the Cryptlib API is large - with over 65 calls and 350 pages of documentation 

• a lot of design effort was required to produce a Tel binding that is both “Tclish” (i.e. comfortable 
for Tel developers) and also close enough to the extensive Cryptlib documentation to avoid the need 
for Tel specific documentation 

• during the implementation it became apparent that there existed an opportunity to provide higher 
level “wrappers” or utility procedures that encapsulated good practice for Tel applications 

• there was also the opportunity to provide an interface to Tel channels, using the Tel transformation 
and stacked channel facilities 

• and finally, there is the opportunity to include non-Cryptlib features within the utility procedures - 
e.g. access to Tcllib[4] cryptographic functions. 

And so the Cryptkit project started - with the goal of producing a comprehensive cryptographic ex¬ 
tension for Tel based on (but not restricted to) the Cryptlib toolkit. 


17 



18 


CRYPTKIT - A CRYPTOGRAPHIC EXTENSION FOR TCL 


Cryptlib Overview 

Cryptlib is a general-purpose encryption toolkit written by Peter Gutmann, a self-confessed “Professional 
Paranoid” in the Department of Computer Science at the University of Auckland. Cryptlib is described as 
“a layered set of security services and associated programming interfaces that provides an integrated set 
of information and communications security capabilities” [5]. In summary, it is a powerful, portable and 
comprehensive security library written in C, but with an “object-like” interface. 

Cryptlib provides three levels of interface: 

• a high-level interface providing secure data enveloping, secure communications sessions and certificate 
management 

• a medium-level security services interface providing key exchange, digital signature, key generation 
and key management 

• a low-level encryption services interface providing access to native and third-party encryption services 
(including hardware crypto devices), and a key store interface to native and third party database 
services 
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Cryptlib supports a wide range of ciphers (inc. Blowfish, DES/3DES, IDEA, RC2/4/5), message digests 
(inc. MD2/4/5, SHA-2/256/384/512), message authentication codes (inc. HMAC-MD5, HMAC-SHA1) 
and public key algorithms (inc. Diffie-Hellman, DSA, RSA, ElGamal). It is also full multi-threaded and 
extensible with new algorithms. 

It is released under a dual license - it is free for non-commercial use and can be licensed for commercial 
use. 

Being a portable and well-documented C library, Cryptlib was an ideal candidate to be used as the 
basis for a Tel extension. 


First steps - Cryptkit VI 

The first version of Cryptkit stayed quite close (in style) to the Cryptlib API. In particular it relied on 
Cryptlib’s data enveloping rather than a more “Tel friendly” or Object Oriented approach. 

There were a number of reasons for taking this approach 

• to leverage the existing documentation of the Cryptlib API 

• to keep the Tel bindings relatively thin 

• to defer designing a more abstracted interface until there was practical experience at using Cryptkit 
and Cryptlib 

For example, consider the following example that creates a general purpose data envelope “e” using the 
higher-level Cryptlib API 

package require cryptkit 
namespace import cryptkit::* 
cryptInit 

cryptCreateEnvelope e CRYPT_UNUSED CRYPT_FORMAT_CRYPTLIB 
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Note that in version 1 all Cryptkit procedures live in the “cryptkit” namespace, and that procedure 
names correspond directly to the Cryptlib C API function. 

The cryptlnit procedure must be called once to initialise Cryptlib, otherwise any Cryptkit procedures 
will return an error. All Cryptkit VI calls return either CRYPT_OK or CRYPTJERROR, as appropriate. 

Now consider the cryptCreateEnvelope procedure invocation - this calls the equivalent C API function 
with three arguments 

• the first is the name of a Tel variable to store ID of the data envelope 

• the second is the user who owns the envelope - Cryptkit supports one user per process and so passes 
the Cryptlib symbol CRYPTJJNUSED indicating the default user 

• the format for the enveloped data - in this case the default CRYPT jFO RMAT.CRYPTLIB format 

Assuming the invocation of cryptCreateEnvelope works it will return CRYPT.OK and the Tel variable 
“e” will be set to an integer value (e.g. 6) indicating the object number within Cryptlib. This value can 
be used in subsequent calls to manipulate the Cryptlib encapsulation object. 

for example, consider the following example in C — digitally signing an envelope 

CRYPT_ENVELOPE cryptEnvelope; 
int bytesCopied; 

cryptCreateEnvelope(fecryptEnvelope, CRYPT_UNUSED, 

CRYPT_FORMAT_CRYPTLIB); 


/* Add the signing key */ 

cryptSetAttribute!cryptEnvelope, CRYPT_ENVINFO_SIGNATURE, 

SigKeyContext) 

/* Add the data size information and data, wrap up the processing, 
and pop out the processed data */ 
cryptSetAttribute!cryptEnvelope, CRYPT_ENVINFO_DATASIZE, 

messageLength); 

cryptPushData!cryptEnvelope, message, messageLength, ftbytesCopied) ; 
cryptFlushData!cryptEnvelope); 

cryptPopData!cryptEnvelope, envelopedData, envelopedDataBufferSize, 

febytesCopied); 

cryptDestroyEnvelope(cryptEnvelope) ; 

The Tel equivalent using Cryptkit VI is 

cryptCreateEnvelope e CRYPT.UNUSED CRYPT_FORMAT_CRYPTLIB 
cryptSetAttribute $e CRYPT_ENVINFO_SIGNATURE $sigKeyContext 
cryptSetAttribute $e CRYPT_ENVINFO_DATASIZE \ 

[string length Imessage] 
cryptPushData $e $message bytesCopied 
cryptFlushData $e 

cryptPopData $e buffer Ibufsize bytesCopied 
cryptDestroyEnvelope $e 

A further example is a script to: 

• create a key pair and certificate 

• use the key pair to sign the certificate 

• add the key pair and certificate to a key set, 

• write the certificate chain to a file 
cryptlnit 

cryptAddRandom NULL CRYPT_RANDOM.SLOWPOLL 

• Create key pair 

cryptCreateContext keyPair CRYPT.UNUSED CRYPT_ALGO_RSA 
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cryptSetAttributestring $keyPair CRYPT_CTXINFO_LABEL "ca" 
cryptSetAttribute $keyPair CRYPT_CTXINFO_KEYSIZE 128 
cryptGenerateKey SkeyPair 

# Create cert 

cryptCreateCert cert CRYPT.UNUSED CRYPT_CERTTYPE_CERTIFICATE 
cryptSetAttribute $cert CRYPT_CERTINFO_SELFSIGNED 1 
cryptSetAttribute $cert CRYPT_CERTINFO_CA 1 

cryptSetAttribute $cert CRYPT_CERTINFO_SUBJECTPUBLICKEYINFO SkeyPair 
cryptSetAttributeString $cert CRYPT_CERTINFO_COUNTRYNAME "au" 
cryptSetAttributeString $cert CRYPT_CERTINFQ_COMMONNAME $commonName 

# Sign cert with keyPair 
cryptSignCert $cert $KeyPair 

# open key store 

cryptKeysetOpen keySet CRYPT.UNUSED CRYPT_KEYSET_FILE "keyset.pl5" \ 

CRYPT_KEYOPT_CREATE 

# Add keyPair and cert chain to pkcsl5 keyset (.pl5) 
cryptAddPrivateKey SkeySet SkeyPair "password" 
cryptAddPublicKey SkeySet $cert 
cryptKeysetClose SkeySet 

# Write out cert chain to pkcs7 file (.p7b) 

cryptExportCert buffer bufferLength CRYPT_CERTFORMAT_CERTCHAIN $cert 
set fos [open $label.p7b w] 
puts $fos Sbuffer 
close $fos 

# Cleanup 

cryptDestroyContext $cert 
cryptDestroyContext SkeyPair 
cryptEnd 


Problems and opportunities 

As can be seen in the examples given - the Cryptkit VI Tel API is very similar in style to the C API. 
Whilst this does have the advantages listed previously, it does result in an interface that is less than ideal 
for a Tel developer for a number of reasons: 

• the Tel programmer has to be concerned about integer versus string attributes even though Tel is a 
type-less language (e.g. cryptSetAttribute versus cryptSetAttributeString) 

• arguments that are never used, or are always set to a fixed value still appear in the Tel procedure call 
(e.g. the user arguments such as that in cryptCreateEnvelope are always set to CRYPT.UNUSED) 

• the interface is somewhat verbose - e.g. prefixing all symbols with CRYPT, is unnecessary when we 
know that (for example) the third argument to cryptCreateEnvelope will always be the format 

• likewise, given Cryptkit procedures are in their own namespace there is no need to prefix each 
procedure with “crypt” 

• the cryptkit namespace could be shortened to crypt - giving more readable procedure names like 
crypt:: CreateEnvelope 

But perhaps the main problem is that the interface isn’t “Tclish” - that is, it doesn’t follow the practices 
and conventions that have become typical in the Tel world. 
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The second iteration - a more Tclish API 

The most significant change in the V2 API is that procedures now return a ’’handle” which can then be 
manipulated in an object oriented fashion 

Consider again the example of digitally signing an envelope. Using the V2 API this looks like the 
following: 

set e [crypt::CreateEnvelope FORMAT_CRYPTLIB] 

$e set ENVINFCLSIGNATURE $sigKeyContext 

$e set ENVINFO_DATASIZE [string length $message] 

$e PushData $message 
$e FlushData 

set buffer [$e PopData $bufsize] 

$e destroy 

Some points to note are: 

• CreateEnvelope returns an object oriented “handle”, rather than just an internal ID returned from 
Cryptlib 

• the “handle” is a Tel command which can be invoked like any other Tel command 

• procedures that operate on an envelope handle are available as methods (or sub-commands) to the 
handle 

• the envelope handle has set and get methods which replace the SetAttribute/SetAttributeString and 
GetAttribute/GetAttributeString commands 

• Cryptkit now lives in the crypt namespace and the “crypt” prefix has been removed from the Cryptkit 
procedure names 

• the CRYPT, prefix is now optional on Cryptlib symbols 
A more complex example follows: 

# Hash some data 

set sha [crypt::CreateContext ALGCLSHA] 

$sha Encrypt "hello I am data to hash" 

$sha Encrypt "" ;# end of data 

# Generate DSA key 

set dsa [crypt::CreateContext ALGCLDSA] 

$dsa set CTXINFO_LABEL "testkey" 

$dsa GenerateKey 

# Produce a signature 

set buffer [$dsa CreateSignature $sha] 

# Validate the signature 

if {[$dsa CheckSignature $buffer $sha]> { puts OK! > 

# Generate a symmetric key 

set aes [crypt::CreateContext ALG0_AES] 

$aes GenerateKey 

# Generate a symmetric key to wrap the first one 
set des [crypt: .-CreateContext ALG0_3DES] 

$des set CTXINFO_KEYING_SALT "this is salt" 

Ides set CTXINFO_KEYING_VALUE "secret password" 

# Wrap the first key in the second 
set buffer [$des ExportKey $aes] 


# Query the signature blob 
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QueryObject Sbuffer i 
parray i 

The parray command outputs the following 


i(cryptAlgo) 

i(cryptMode) 

i(hashAlgo) 

i(objectType) 

i(salt) 

i(saltSize) 


CRYPT_MODE_CBC 
CRYPT_MODE_CBC 
CRYPT_M0DE_N0NE 
CRYPT_MODE_ECB 
this is the salt 
16 


Higher-level utility procedures 

Cryptkit V2 goes further and introduces a number of utility procedures that make it even easier to perform 
common cryptographic functions from Tel. These include: 

• cert 

• key 

• encrypt 

• decrypt 

• hash 

• option 

• session 

Utility procedures accept an argument that specifies the procedure type (e.g. a certificate type), and a 
series of argument pairs that correspond to Cryptlib attributes and values. 

The cert utility procedure is used to create a certificate - the certificate type defaults to 
CERTTYPE-CERTIFICATE if not specified. For example, the command 

crypt::cert -selfsigned 1 -ca 1 -publickey 1 -simple 1 \ 

-name "My name" 

will run the following V2 commands 

set c [crypt::CreateCert CERTTYPE.CERTIFICATE] 

$c set selfsigned 1 

$c set CERTINFCLSUBJECTPUBLICKEYINFO 1 
$c set commonname "My name" 

$c set CERTINFCLXYZZY 1 
$c SignCert "" 

The key utility procedure accepts an argument that specifies the key type (e.g. IDEA), and a flag to 
specify the key text. For example, the command 

set k [crypt::key idea -key $key] 

will run the following V2 commands 

set k [crypt::CreateContext ALGCLIDEA] 

$k set CTXINFCLKEY $key 
$k GenerateKey 

The encrypt utility procedure accepts a session key and a list of data values. Similarly the decrypt 
utility procedure does the reverse and returns clear text. So, to use the above key to encrypt and decrypt 
a clear text message we could do something like 
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set c [crypt: .-encrypt -sessionkey $k $message] 
set u [crypt::decrypt -sessionkey $k $c] 
if {$u eq $message}- { 
puts worked 
} else -[ 

puts failed 

> 

The hash utility procedure is used to hash text using one of the algorithms supported by Cryptlib. For 
example 

set msg "this is the message" 

foreach algo {md2 md4 md5 ripemdl60 sha} { 

puts "[format %-10s $algo] = [crypt::hash $algo $msg]" 

will output the following 

md 2 = falla5d972dl8efb8acd4e70242890f 0 

md 4 = ba370f9c73940645ff32dab913764697 

md5 = e30d2a38a4a5dl55aal8f09aelal55ab 

ripemdl60 = c721e9ed4bfa87039049clbaa8f73e8ea8d37367 

sha = C37c7b5326ce400d23d9807bl3flea396861a0b5 

The hash procedure does quite a bit of work behind the scenes. For example, the following command: 
crypt::hash md5 $msg 

This will run the following V2 commands, which return the hash value as a text formatted string (which 
is much more useful to a Tel program than the binary data) 

set k [crypt:CreateContext ALG0_MD5] 

$k Encrypt $msg 
$k Encrypt "" 

set bin [$k get CTXINFCLHASHVALUE] 
set len [expr {2*[string length $bin]>] 
binary scan $bin H$len hash 
$k destroy 
return $hash 


The session utility procedure can be used to create client 
secure session facilities. Supported session types are: 


or server sessions using one of the Cryptlib 


• SSH 

• SSL 

• TLS 

• CMP 

• SCEP 

• RTCS 

• OCSP 

• TSP 


For example, to create an SSL server session listening on port 1080 use the following: 

set s [crypt::session ssl -type server -port 1080] 

Similarly, to create an ssh client session for the current user, connected to host www.server.com on the 
default ssh port use: 
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set c [crypt::session ssh -privatekey $key -host www.server.com] 

where Skey is a key object created by the key utility procedure. 

You can then write data to the ssh server using the following: 

$c puts "Is -1" 

The session “puts” sub-command is analogous to the Tel puts command, and will call crypt::PushData 
and crypt ::FlushData. 

You can read data back from the ssh server using 

while {[$c gets line] >=0 } { 
puts $line 

> 

The session “gets” sub-command is analogous to the Tel gets command, and will call crypt::PopData 
and split the returned value into lines. 

And finally there is an option utility procedure which can be used to set and get Cryptlib global 
configuration options. To get a Cryptlib setting use the following form: 

crypt::option optionclass attribute 

The two arguments are concatenated to produce the name of the Cryptlib option - so to retrieve the 
default hash algorithm (CRYPT.OPTIONJENCR-HASH) you would use 

crypt::option encr hash 

and to produce a hash using the default algorithm we’d use something like 
set def [crypt::option encr hash] 

puts "default hash ($def) = [crypt::hash $message]" 
which would produce 

default hash (ALGCLSHA) = c37c7b5326ce400d23d9807bl3fIea396861a0b5 

To set global options specify a value as the third parameter. For example, to set the default hash 
algorithm to MD5 you would use 

crypt::option encr hash ALGCLMD5 

Setting an option usually only remains in effect during the current Cryptkit session (i.e. until the Tel 
interpreter using Cryptkit exits or the crypt::End command is called). 

Options can be saved to permanent storage using the option “save” sub- command. This will make 
them available to be used in subsequent Cryptkit sessions: 

crypt::option save 

The option “dump” sub-command can be used to display all Cryptlib global options, grouped by option 
class (particularly useful when developing an application using Cryptkit) 

% crypt::option dump 
Cert 

COMPLIANCELEVEL = COMPLIANCELEVEL_STANDARD 
UPDATEINTERVAL = 90 

REQUIREPOLICY = COMPLIANCELEVEL_REDUCED 
VALIDITY = 365 

SIGNUNRECOGNISEDATTRIBUTES = COMPLIANCELEVEL_OBLIVIOUS 

Cms 

DEFAULTATTRIBUTES = 1 


Device 
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PKCS11_HARDWAREONLY = 0 
PKCS11_DVR01 = 
PKCS11_DVR02 = 
PKCS11_DVR03 = 
PKCS11_DVR04 = 
PKCS11_DVR05 = 


Encr 

MAC = ALGO_HMAC_SHA 
ALGO = ALG0_3DES 
HASH = ALG0_SHA 


Info 

MINORVERSION = 1 
STEPPING = 1 
MAJORVERSION = 3 

COPYRIGHT = Copyright Peter Gutmann, Eric Young, OpenSSL, 

1994-2004 

DESCRIPTION = cryptlib security toolkit 


Keying 

ITERATIONS = 500 
ALGO = ALG0_SHA 


Keys 

LDAP_OBJECTCLASS = inetOrgPerson 
LDAP_EMAILNAME = mail 

LDAP_CRLNAME = certificateRevocationListjbinary 
LDAP_OBJECTTYPE = 0 

LDAP_CACERTNAME — cACertificate;binary 


„n In summary, the \' 2 utility procedures provide a more convenient and simplified way to access the 

derlying Cryptlib functionality for common tasks, without precluding the use of the underlying API for 
more complex tasks. 

And since they are scripted in Tel, it is likely that their number and scope will improve over time as 
more experience is gained with using Cryptlib from Tel. 


Implementation 


Interfacing Cryptlib with Tel 

There are three main ways of interfacing a C library such as Cryptlib with Tel 
• manually create the interface code in C using the Tel C API 


• generate an interface using SWIG (the Simplified Wrapper and Interface Generator) [6] 

• use Critcl (“C Runtime in Tel”) [7] to generate an interface 


With 65+ functions to wrap the first option wasn’t strongly considered. 

Both SWIG and Critcl are used to generate interfaces from Tel to C libraries. SWIG uses a small 
mterface file that specifies which functions are to be wrapped, and generates C code that calls the Tel 
C API to perform the binding. When compiled, the resulting shared library can be loaded into a Tel 
interpreter and the C functions called from Tel. 

Critcl uses a different approach - C code is embedded in a Tel script and transparently compiled into a 
shared library that is installed m a Tel package. At runtime the library for the current platform is loaded 
when the calling application invokes “package require”. 

Critcl was chosen for a number of reasons 


• the author’s involvement with the Critcl project and resulting level of familiarity 

• the Tel specific nature of Critcl 
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• the opportunity to further improve Critcl as a facility for wrapping and binding to C libraries from 
Tel 

But rather than build an interface procedure for each of the Cryptlib functions, the decision was taken 
to try a higher level approach - develop a “little language” that describes the various Cryptlib functions 
and their arguments. This description is used to generate Critcl code, which in turn builds Cryptkit. 

Cryptlib is particularly suited to this approach because it uses integer values for symbolic constants 
and object names, and all Cryptlib functions return an integer that indicates success (i.e. CRYPT-OK) 
or failure (i.e. CRYPTJ3RR0R). Any return values are set via pointer (i.e. reference) arguments, with 
additional arguments specifying the maximum length and actual length for void* return values. 

So function arguments fall into just a few categories: 

• integer values corresponding to Cryptlib symbols (e.g. CRYPT_CONTEXT) 

• integer values representing Cryptlib encapsulated object identifiers 

• char* arguments (e.g. a null-terminated character string holding a password) 

• void* arguments (e.g. a character array holding random data) with an associated integer argument 
specifying the length of the data 

• integer and char* return arguments 

• void* return arguments, with an associated length and maximum length integer argument 

Armed with this information, we can begin to describe the Cryptlib API in our little language. 


Describing Cryptlib functions 

Cryptlib functions are defined by a “generate” procedure within the Cryptkit source code. This accepts a 
list of function names and arguments. 

For example 

generate { 

AddPrivateKey { keyset cryptKey password } 

AddPublicKey { keyset certificate } 

AddRandom { randomData randomDataLength > 


} 

The first field is the name of each function, which is followed by a list of arguments. Note that the actual 
Cryptlib function names are prefixed by ’’crypt”, and the Tel procedures that access them are defined in 
the ::crypt namespace, for example: 


::crypt::AddPrivateKey calls cryptAddPrivateKey 

Note also that the above description doesn’t include the type of each argument. This is specified by 
optionally adding a single character “suffix modifier” to each argument definition. The common suffix 
modifiers are 

* const char* argument 

= const void* argument, next argument is the length 
return integer 

% return void*, next argument is the length being returned 

@ const int argument that is absent from Tel procedures calls and always set to CRYPT-UNUSED when 
calling C functions 


For example: 
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generate { 

AddPrivateKey { keyset cryptKey password* 

AddPublicKey { keyset certificate 

AddRandom { randomData= randomDataLength 


> 

> 


CreateCert 

PopData 


{ certificate+ cryptUser® certType > 

{ envelope buffer'/, length bytesCopiedfe > 


So, the little language is just an invocation of the “generate” procedure, enumerating each function 
and its arguments, with suffix modifiers to specify the argument types. 


Variable length argument data 

There are a number of Cryptlib functions that return pieces of data of varying lengths. 

For example cyptCreateSignature is used to digitally sign a piece of data and it returns a signature in 
a buffer specified in the function call. 

Within Cryptlib such functions can be called with a NULL argument and Cryptlib will return the 
length of the buffer required, without actually generating the data. Also, a number of function arguments 
are rnteger vanabffis that will be set to the length of the data being returned by Cryptlib, and so don’t 
need to be in the Tel API. 

Similarly, there are a number of functions that accept void * arguments with a companion integer 
argument to specify the length of the data. Since the length of all Tel data can be obtained at run time 
it makes sense for the interface to insert the length automatically. 

To support these features we use introduce four additional s uffix modifiers 

: Instructs Cryptkit to call the function first with a NULL argument, allocate a return buffer of appropriate 
size and then call the function again 

! Tells Cryptkit that the argument should not appear in the Tel procedure interface, and that instead 
L-ryptkit should pass a predefined maximum length value (arbitrarily set to 32000) 

? Tells Cryptkit that the variable will be set by Cryptlib, and doesn’t need to be in the Tel API 

# Tells Cryptkit to use the length of the previous void* argument (i.e. the length of the Tel ByteArrav 
corresponding to the void* argument) 

For example, the description of cryptCreateSignature and cryptCheckSignature is 
generate { 


CheckSignature { signature= length# sigCheckKey hashContext } 
CreateSignature { signature: maxlength! signatureLength? 

signContext hashContext > 


When invoking these from Tel 

• from crypt: :CheckSignature omit the length argument 

• from crypt::CreateSignature omit the maxlength and signatureLength arguments 


Cryptlib objects 


Several functions accept integer arguments that are object (i.e. envelope) identifiers within 
discussed previously, Cryptlib V2 encapsulates these within an object command 
These need special handling in Cryptkit V2 via the following suffix modifiers 


Cryptlib and, 


-p creates a Cryptkit object and returns a handle comprising the 
Cryptlib envelope ID (e.g. cert!23) 


argument name concatenated with the 
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- if the argument is an integer then it is assumed to be a Cryptlib envelope ID and passed straight to 
Cryptlib, otherwise Cryptkit tries to find an object of this name and passes the object’s envelope ID 
to Cryptlib (e.g. certl23 will pass 123) 

same as except it destroys the corresponding Tel object before returning from the procedure 
This allows us to add descriptions such as: 

generate { 

CreateCert 
AddPublicKey 
AddPrivateKey 
DestroyCert 

} 

Taking the CreateCert command as an example, this is invoked as follows 

•/. set cert [crypt:: CreateCert CERTTYPE_CEETIFICATE] 

*/, $cert set CERTINFO_SELFSIGNED 1 
7 $cert set CERTINFCLCA 1 
7 puts $cert 
certificate395 

So Cryptkit has created an object command “certificate395” which corresponds to the Cryptlib certifi¬ 
cate object whose ID is 395. 


{ certificate+ cryptUser® certType } 
{ keyset- certificate- } 
{ keyset- cryptKey- password* } 
{ cryptCert_ } 


Cryptlib symbols 

There are a number of Cryptlib symbols that need to be made available to the Cryptkit program (e.g. 
CRYPT-CERTTYPE-CERTIFICATE). These symbols are defined by a # define or enum in the cryptlib.h 

header file. ., . , c 

These were made available to the Tel programmer by extending Critcl with a new cntcl::cdefines 

command to allow mapping between C defines and Tel variables. For example, 
critcl::cdefines CRYPT_* ::crypt 

This command tells Critcl to make Cryptlib symbols beginning with CRYPT- available as variables 
within the Tel ::crypt namespace - both with and without the leading CRYPT_. 

Critcl does this by pre-processing any C code in cryptlib.tel script using the appropriate C compiler 
preprocessor flag (e.g. gcc -E). The preprocessed C code is scanned for #defines and enums, and the Tel C 
API function calls are generated to set Tel variables to the corresponding integer values. When the resulting 
shared library is loaded by the Cryptkit package it sets these variables within the crypt namespace. 

This will allow a program to reference a Cryptlib symbol like any other Tel variable, for example: 

crypt::CreateCert $CERTTYPE_CERTIFICATE 

But it is more convenient to just to use the symbol name (i.e. without de- referencing the Tel variable) 
when calling a Cryptkit command, so we introduce another suffix modifier 

“ the integer argument is the name of a Cryptlib /(define/enum 

which allows us to declare CreateCert as 

generate { 

CreateCert { certificate+ cryptUser® certType > 

If the argument is an integer it is passed throught to the Cryptlib function, otherwise it is assumed to 
be a symbol name and the value of the corresponding Tel variable is passed through. 

This allows us to invoke CreateCert via 


crypt::CreateCert CERTTYPE_CERTIFICATE 
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Generated C code 

The description of the Cryptlib API is used to generate interface Critcl ccommand procedures (i.e. C 
embedded in Tel, with access to arguments via the Tel C Object API). 

For example, the description of the crypt ::CreateCert function: 

CreateCert { certificate+ cryptUser® certType" > 

results in the following Critcl commands being generated 

critcl::ccommand CreateCert {data ip objc objv} { 
int ret; 
int argl; 
int arg2; 
int arg3; 

Tcl_0bj *obj3; 
if (objc != 2) { 

Tcl_WrongNumArgs(ip, 1, objv, "certType") ; 
return TCL_ERR0R; 

> 

arg2 = CRYPT_UNUSED; 

if (GetIntOrConstArg(ip, objv[l], &arg3) == TCL_ERR0R) { 

Tcl_AddErrorInfo(ip, "\" (argument 1 to CreateCert)"); 
return TCL_ERR0R; 

> 

ret = cryptCreateCert(feargl, arg2, arg3); 
if (ret < CRYPT_0K) 

return cryptkitError(ip, ret, 0); 
cryptkitNewObj(ip, Tcl_NewStringObj("certificate",-l), 

Tcl_NewIntObj(argl)); 

return TCL_0K; 

} 

Points to note include 

• the Cryptlib cryptCreateCert function call 

• the helper functions GetlnOrConstArg, cryptkitError and cryptkitNewObj 

• arguments and return values are handled via Tel Objects 

• the first argument (argl) is returned as a Tel object (cryptkitNewObj sets the return value) as per 
the + suffix modifier 

• arg2 ( is set to CRYPT AJNUSED, as per its description with the @ suffix modifier 

• the third argument is either an integer or symbol as per the suffix modifier 

Building Cryptkit 

Building Cryptkit is a two-stage process 

• first you build a static Cryptlib library (the details of which vary by platform and are beyond the 
scope of this paper) 

• then you build Cryptkit using Critcl, 

The result is a cross-platform Tel package that can be included into your application to make it “Cryp¬ 
tkit enabled”. 

The Cryptkit source is a single file - cryptkit.tcl. It assumes a copy (or link to) the cryptlib.h header 
is in the same directory/folder. Likewise you need a copy of the static Cryptlib library for each platform 
you want to build on. And finally you need a copy of the Critcl program, downloadable from the Critcl 
home page [7]. 

Once all these are available, on each platform you build Cryptkit using: 
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$ critcl -pkg cryptkit 

If your source directory is cross-mounted to multiple machines then the lib/cryptkit directory will have 
the Cryptkit shared library for each platform added to it. This directory adheres to the Tel “package” 
convention and so is ready for use in any Tel application. 

Cryptkit has been deployed on Linux (both x86 and ARM), MacOS X and Windows. It should be 
portable to any platform supported by Cryptlib (which seems to be most platforms) and Critcl (anywhere 
a GNU toolchain is available, and then some). 


The Future 

Future developments include providing access to non-Cryptlib functionality. In particular, this will include 
interfaces to the Tcllib cryptographic modules from within the Cryptkit utility procedures, including the 
pure Tel implementations of AES, DES, MD4, MD5, MD5crypt and SHA1. 

Another development will be support for Tel stacked channels. Stacked channels allow transformations 
or filters to be applied to I/O channels (both files and socket). This allows the filters to intercept all 
read/write activity on the channel and modify the data. This will allow Cryptkit functionality to be 
applied to existing Tel channels, combining the full power of Cryptkit with Tel’s powerful event driven 
I/O model. 

And finally, there is a planned implementation of the recently endorsed X9.95 Trusted Time Stamp 
Management and Security standard. 


Licensing 

Cryptkit is released under a Tcl-friendly BSD style Open Source license. 

As mentioned previously, the underlying Cryptlib security toolkit is distributed under a dual license - 
it is free for non-commercial use and commercial licenses are available. Developers wishing to use Cryptkit 
in commercial products should ensure that they review the Cryptlib license available at [2]. 


Conclusion 

Cryptkit has proven useful at two levels 

• it has provided a cryptographic extension for Tel, that is both comprehensive and “Tel friendly” 

• it has been led to the development of new ways of wrapping C libraries for use as Tel extensions 

And along the way, the project has led to further improvements to the already useful Critcl utility. 

It’s certainly not perfect, and in many ways the rough edges are yet to be “knocked off’ as it begins to 
be used in “real” projects. 

But by any measure, it’s been worthwhile. And fun 1 . 


Acknowledgements 

Thanks are due to Mike Doyle of Eolas Technologies Inc, for the initial Cryptkit concept, the name and 
the ongoing sponsorship of the development. 

Thanks also to Pat Thoyts for his help in building a Windows version of Cryptlib, and for his general 
suggestions, support and encouragement. And for Jean-Claude Wippler’s help in building the Windows 

port. . . . 

Likewise Jeff Hobbs who has provided ongoing insight into several deep technical issues - in particular 

on the quality of the Tel C API code generated. 

Steve Redler IV assisted with the Linux/ARM port, as well as providing feedback and suggestions. As 
did Donal Fellows, Andreas Kupries and several other people in the Tel community. 

Mark Roseman, Donal Fellows, Jean-Claude Wippler and Mike Doyle reviewed the draft of this paper. 
And finally Peter Gutmann, for producing Cryptlib and for his assistance during the development of 
Cryptkit. 


1 For some definition of “fun’ 



REFERENCES 


31 


References 

1. The 11th Annual Tcl/Tk Conference - 
http: / / www.tcl.tk/community/tcl2004/ 

2. Cryptlib - http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ 

3. TLS - http://tls.sourceforge.net/andhttp://wiki.tel.tk/tls 

4. Tcllib - http://tcllib.sourceforge.net 

5. The Cryptlib Security Toolkit Version 3.2, auth. Peter Gutmann, pg 2 
ftp://ftp.franken.de/pub/crypt/cryptlib/manual.pdf 

6. SWIG - the Simplified Wrapper and Interface Generator - 
http://swig.sourceforge.net/ 

7. Critcl - C Runtime in Tel - 

http://www.equi4.com/critcl.html 


Appendix 1 - Cryptlib C API Description 

# function arguments 

# default is "const int" 

# suffix modifiers to alter this 

# ar g is name of #define/enum in cryptkit namespace 

# * char * 

# = void * 

# object handling 

# + creates Cryptkit object and returns handle comprising argument 

# name+cryptlib number (e.g. certl23) 

# - if integer then pass to Cryptlib, otherwise tries to find 

# Cryptkit object and passes integer value to cryptlib 

# _ same as excepts destroys the corresponding Tel object 

# the following indicate values to be returned from the Tel proc 

# & return int 

# % return void *, next arg is length 

# : return void *, call with NULL to get length of string 

# the following arguments are not in the Tel API, only the C API 

# # use length of previous void * 

# ! max length - always follows : 

# ? actual length returned by C API 

# @ set to CRYPT.UNUSED in C API 

generate { 


AddCertExtension 

{ certificate- oid* criticalFlag extension= 
extensionLength# } 

AddPrivateKey 

{ keyset- cryptKey- password* > 

AddPublicKey 

{ keyset- certificate- } 

AddRandom 

{ randomData= randomDataLength" } 

AsyncCancel 

{ cryptObject- } 

AsyncQuery 

{ cryptObject- > 

CAAddltem 

{ keyset- certificate- } 

CACertManagement 

{ certificate* action keyset- caKey- 
certRequest- } 

CAGetltem 

{ keyset- certificate* certType keyIDtype keyID= 

CheckCert 

{ certificate- sigCheckKey- > 

CheckSignature 

1 signature= length# sigCheckKey- hashContext- > 

CheckSignatureEx 

{ signature= length# sigCheckKey- hashContext- 
extraDatafe > 

CreateCert 

{ certificate* cryptUser® certType" } 
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CreateContext { context+ cryptUser® cryptAlgo" } 

CreateEnvelope { envelope+ cryptUser® formatType" > 

CreateSession { session+ cryptUser® sessionType" } 

CreateSignature { signature: maxlength! signatureLength? 

signContext- hashContext- } 

CreateSignatureEx { signature: maxlength! signatureLength? 

formatType signContext- hashContext- 
extraData- } 

Decrypt { cryptContext- buffer^ length# } 

DeleteAttribute { cryptObject- attributeType > 

DeleteCertExtension { certificate- oid* } 

DeleteKey { cryptObject- keyIDtype keyID= } 

DestroyCert { cryptCert_ } 

DestroyContext { cryptContext_ } 

DestroyEnvelope { cryptEnvelope, } 

DestroyObject { cryptObject, } 

DestroySession { cryptSession, } 

DeviceClose { device > 

DeviceCreateContext { cryptDevice contextt cryptAlgo } 

DeviceOpen ■{ devicefe cryptUser® deviceType name* } 

DeviceQueryCapability { # handled explicitly by C function } 

Encrypt { cryptContext'/, buffer= length# } 

End { > 

ExportCert { certObject: maxlength! certObjectLength? 

certFormatType~ certificate- > 

ExportKey { encryptedKey: maxlength! encryptedKeyLength? 

exportKey- sessionKeyContext- } 

ExportKeyEx { encryptedKey: maxlength! encryptedKeyLength? 

formatType exportKey- sessionKeyContext- } 
FlushData { cryptHandle- > 

GenerateKey { cryptContext- > 

GenerateKeyAsync { cryptContext- } 

GetAttribute { # handled explicitly by C function > 

GetAttributeString { cryptObject- attributeType" value: 
valueLength? } 

GetCertExtension { certificate- oid* criticalFlag& extension: 

maxlength! extensionLength? } 

GetPrivateKey { cryptHandle- context+ keyIDtype" keylD* 

password* } 

GetPublicKey { cryptObject- publicKey+ keyIDtype keyID= > 

ImportCert { certObject= certObjectLength cryptUser® 

certificate+ } 

ImportKey { encryptedKey= maxlength# importContext- 

sessionKeyContext- } 

Init { # handled explicitly by Tel procedure } 

KeysetClose I keyset, > 

KeysetOpen { keyset* cryptUser® keysetType" name* options" 

> 

PopData { envelope- buffer'/, length bytesCopied? > 

PushData { envelope- buffer= length# bytesCopiedfe } 

QueryCapability { # handled explicitly by C function > 

QueryObject { # handled explicitly by C function > 

SetAttribute { # handled explicitly by C function > 

SetAttributeString { cryptObject" attributeType" value= 
valueLength# > 

SignCert { certificate- signContext- > 


> 
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Creating and administrating a laboratory with a number of PCs running LINUX on a network to cater 
to a large number of users can be a challenging task specially since users are always on the lookout for 
trying new software and are well aware of hacking and cracking software available freely on the internet. 
The system administrator is always hard pressed to meet the growing needs for additional software and 
also protect the system against internal as well as external security threats. Based on our experience at 
4000+ users, a recipe for similar environment was summarized. 

A large computing facility can be divided into two major domains. The first domain can be the services 
provided by servers. These services would normally consist of authentication services such as NIS and 
LDAP, naming services such as bind , central file services such as NFS, central mailing systems and 
proxy based web services. 

The second domain can be thought of as the services received and provided by the clients. This paper 
focuses on the second aspect of managing a large computing facility. 

It is a difficult task to monitor many clients running linux and getting automatic feedback of their 
functioning without compromising superuser privilege. System monitoring helps in analyzing clients for 
health checking and hacking. Cloning as well as automatic updating of new packages and configuration files 
are required for simplifying the process of automation. Utilities like xload and chkrootkit are available which 
can help in system monitoring. However, generating log files on so many systems and the corresponding 
report generation can be a difficult job. One can easily perform this job by writing several event driven 
scripts or scripts on the basis of ICMP echo. Such scripts can for instance capture several events of 
unauthorized access to super user privileges. Implementation of automatic updating for deploying new 
packages and distribution of modified configuration files on many machines has been also explored. A 
master system is required to push the updates on the clients. Several such tasks can be automated through 
cron jobs. 

This paper describes the implementation of such tasks with few small scripts and system configuration 
to keep regular vigilance as well as updates as required on time to time basis for the Linux platform. The 
success and failure of these actions must also be reported to the System Administrator through mail. 

Large computing environments need special care for checking health and security breaches across various 
clients. Root passwords may be, maliciously or otherwise, trapped and the lab environment may be 
destroyed if this job is not tackled properly. Regular and automatic monitoring is the only solution to 
counter such threats. The basic steps are followed and then scripts are deployed to suite our needs. Most 
of the steps are general and common in nature. The new systems are installed as per the requirement. All 
free and propriety software are also chosen for installation keeping in mind the different varieties of users. 
This system is tested vigorously and performance is measured like cpu utilization, memory hogging and 
response time. The unnecessary processes/daemons must be stopped to improve the system performance. 
The lilo/grub should be password protected to avoid the users mishandling at boot time. The system 
should not permit root login directly on the console but one may get root privilege through su command 
only. 

Cloning is another area where one may face NIC problem. One may use g4u, g4l or Norton ghost for 
cloning PCs. All have their own advantages and disadvantages. DHCP play a crucial role in minim izing 
your efforts towards putting hostname, ipaddress, nameserver, gateway and netmask. 
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Reporting ‘UP/Down’ condition of the systems are preliminary but essential part of the system man¬ 
agement. This kind of reporting is based upon ICMP echo using ping command. The listing of the script 
is shown below. This uses one file “discardlist” containing a list of systems temporarily or permanently 
discarded because of some reasons. 

#!/bin/sh 

#This script pings the hosts and send an email in case of no response from the hosts 

logfile="/usr/local/sbin/pingchecker/pagefile" 

pagefile="/usr/local/sbin/pingchecker/pagefile" 

echo subject: Linux Lab. Systems Status > pagefile 

i-10 

while [$i -le 60] ; 
do 

grep -q $i /usr/local/sbin/pingchecker/discardlist 

if [$i -gt 0] 

then 

‘/sbin/ping -c 2 ccpc0$i l>/dev/null 2>&1‘ 

#if 100% packet loss - System is down 

if [$? -gt 0] 

then 

echo ccpc0$i is down on ‘date 1 >> logfile 
echo ccpc0$i is down on ‘date' » pagefile 
fi 
fi 

I = ‘expr $i + 1‘ 

Done 

#Go ahead and mail 
mail aftab@iitk.ac.in 

There are numbers of utilities or commands like OpManager, free, top, vmstat, sar, iostat in LINUX 
which can produce statistics for CPU, memory, I/O utilization. One can also use tcpwatch, tcpdump, 
ethereal etc. for network utilization. One can easily extract the useful information from the outputs of the 
aforesaid commands and analyze the systems and their performance. But these tools are generally used 
for Server where compute jobs are running. Statistics of the servers are necessary so that users can share 
the resources equally or on priority basis. Since this article is covering the client management, there is no 
need to go into details of these tools. One can use these tools for a group of the clients in case it becomes 
essential sometimes. 

One can also write a small script to report security lapse. One may hack the system and becomes super 
user. The instant information to the administrator is a valuable asset to catch holds the culprit. The 
next script reports the System Administrator for any breach of security like becoming Super User on any 
system. 


#! /bin/sh 

#This script checks whether any user has procured super user privilege, 
set ‘date' 
d = $3 
e = $2 

cat /var/log/messages 1egrep ‘su\(pam-unix\) I gdm\(pam-unix\)‘ > anyfile 
cat anyfile | grep root 1 grep $e\ I grep $d\ > anyfilel 
mail s Super User Info aftabSiitk.ac.in < anyfile2 


The following script may be used for reporting any discrepancies in hardware configuration especially 
hard disk and memory. A computer desktop facility in one room is supposed to have systems with similar 
configuration most often and any change in hardware should be reported to system administrator. 


#!/bin/sh 

#This script checks for any disk or memory discrepancies, 
df -k 1 cut -fl 1 grep /$ 1 grep 1832 I tee frl 
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df -k | 

cut -f1 | 

grep /$ 1 

free -b | 

cut -fl 

1 grep Mem 

free -b | 

cut -fl 

1 grep Mem 

if [ ! -s 

frl -a ! 

-s fr2 ] 

then 



mail -s 

"System Information" 

echo hard 

disk different 

fi 




I grep 3724 | tee fr2 

grep 2619 | tee fr3 
grep 2537 | tee fr4 


aftab@iitk.ac.in < anyfilel 


if [ ! -s fr3 -a ! -s fr4 ] 
then 

mail -s "System Information" aftab@iitk.ac.in < anyfile2 
echo Memory is different 
fi 

rm frl fr2 fr3 fr4 


Online updating and modification process 

One can use rsh for pushing updated files from master to clients but this method will need rsh permission 
on the client sides. The rsh permission itself is a security threats in an open environment. It would be uphill 
task to trace out trapped system in such large computing environment. One has to evolve a procedure or 
method which is comparatively secured and fool proof. 

A recipe for the same has been prepared for the implementation of the updating process. A system 
with a large amount of disk space is allowed to export a global directory. This global directory is mounted 
on all clients with read permission. There is a need of a master system also which has the write permission 
on this global directory. This is a centralized machine which must have the permission to store files and 
archives into this global directory. Once this environment has been setup, the master system can be used 
for any kinds of replication, modification and distribution to the client machines. Now a directory is further 
created in /users/share like “users/share/scripts” where script files are kept for each section of the lab. 
These script files keep changing on demands. It is advisable to divide the lab. into sections and keep 
separate script files for separate physically visible sections. 

A sample shell script file with a collection of commands is given below which simply copies the files to 
a specified location and also updates desired rpm packages. The file is named as “L3cronhour.sh” for L3 
section. Here it would be necessary to mention that LI, L2 and L3 are sections. 
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# !/bin/sh 

#This script simply copy the files into specific directory or install selected package, 
cd /users/share 
cd /usr/local 

tar -xvf /users/share/java.tar 
cp /users/share/esclOl.profile /etc/profile 
In -s /usr/local/j2sdkl,4.2_04/bin/javac javac 
unzip /users/share/j avabookEd3.zip 
mv javaoc\ ed3javabook/ javadoc 
cd /users/share/mozilla 
rpm -Uvh mozilla* 


It is advisable to run these scripts through cron only. One may schedule the execution of these files 
putting them into /etc/cron.hourly or /etc/cron.daily or else as desirable. Few lines have been written as 
shell script which checks the file before execution. This file has been named as “linmaster.sh”. 


#!/bin/sh 

#This script only checks for L3cronhour.sh file to be executed hourly, 
cd /users/share/scripts 

if [ -s /users/share/scripts/L3cronhour.sh ] 
then 

/users/share/scripts/L3cronhour.sh 
fi 


One may require some jobs done within specified time slots. The example script has been presented 
purposely for timely disabling and enabling the services to stop any mal-practicing like file sharing, infor¬ 
mation transaction during examination using ftp, mail etc. Thus many services are first blocked and then 
revert back matching the schedule. One may require to performing this task during examination or test. 

#!/bin/sh 

#This script checks the date and time for running some command to disable services. 

PATH=/bin:/sbin:/usr/sbin:/usr/bin 

Export PATH 

Datel=20050213 

Date2=20050217 

Date3=20050218 

Date4=20050219 

Tl=1330 

T2=1700 

DateStr= ‘ date "+'/.Y , /jn7.d" ‘ 

TimeStr=‘date "+"/ t H“/.M"‘ 

#echo $TimeStr 
#echo $DateStr 
runcmd=two 
dateok=no 

if [ "$DateStr" = $Datel -o "$DateStr" = $Date2 ] 
then 

dateok=yes 

elif [ "DateStr" = $Date3 -o "$DateStr" = $Date4 ] 
then 

dateok=yes 

fi 

#echo $dateok 

if [ $dateok = yes ] 

then 

if [ $TimeStr -ge $tl -a $TimeStr -le $t2 ] 
then 

runcmd=one 
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fi 

fi 

#set_return used by all prgms to set return value 
rval=0 

set_return() { 

x—$? 

If [ $x -ne 0 ] 
then 

echo "ERROR CODE $x" 
rval=l 
fi 
} 

#one_action action to be performed when system is coming up during exam time 
one_action() { 
chmod 700 /bin/mail 
chmod o-x /bin/su 
chkconfig wu-ftpd off 
chkconfig telnet off 
/etc/init.d/sshd stop 
} 

#two_action action to be performed when system is coming up at regular time 

two_action () { 

chmod 755 /bin/mail 

chmod o+x /bin/su 

chkconfig wu-ftpd on 

chkconfig telnet on 

/etc/init.d/sshd start 

if [ "SDateStr" = $Date4 -a STimeStr -ge $t2 ] 
then 

rm -f /etc/rc5.d/S981ocal 
rm -f /etc/init.d/local 
fi 
> 

local_start () { 

if [ "$runcmd" = one ] 

then 

#execute the scripts for the lab 

one_action 

else 

#execute scripts for normal operations 
two_action 
fi 
> 

local_stop () { 
exit $rval 
> 

case $1 in 
start_msg) 

echo "Executing Local Scripts" 
stop_msg) 

echo "Executing Local scripts" 

J I 

‘ start‘) 
local_start 

J } 

‘stop') 
local_stop 
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*) 

echo "usage: $0 {start / stop }" 

J J 

esac 

exit $rval 


LINUX uses many useful tools like up2date, apt-get, yum etc. to manage updates online. All are very 
useful for rpm packages updates. But users are sometimes stuck with slow internet access. 

The described method is meaningful in most of the cases. One may even choose web accessible global 
directory for this purpose. Emergency updates can also be tackled easily. One may define the time slots for 
the execution of the script. The method is quite flexible and very common. The small script can extract 
some useful information to check health and wealth of the system. 


LOG VIEW on client machines 

A method can be implemented where a system administrator sometimes would be able to view the logs of 
a particular client. For this purpose a global scratch directory mountable with write permission to super 
user only needs to be created. A separate directory mounted on each client will be a good choice. Now 
one needs to copy all the different log files like boot log, kernel startup log, security log, system log etc. 
into a separate directory corresponding to each client once in a day. Now logviewer can be configured for 
each client to read their respective file. Thus one can easily view the log files of any client from a single 
machine this way. 


Conclusion 

The described method is very common and simple. One can easily adopt this method. It can be imple¬ 
mented with a web directory accessible from all clients or a simple exportable directory mountable with 
read permission on clients and write permission on the master machine. Vigilance on so many machines is 
a difficult task. System administrator should be able to hold someone responsible for any kind of hacking 
and cracking the system. One of the concerns is super user privilege. One should also be informed through 
mail of non-functioning system. This has been achieved through ping scripts. Further any discrepancies 
like disk capacity or memory on any system should also be reported online for further action. Handling 
users during examination is an uphill task and better ways are stop and restart suspected tasks or services 
before and after the examination. This can be achieved through the script as above. 
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Abstract 

Everybody knows good documentation when they read it. Both from trying to write documentation and 
from trying to guide others in writing documentation, it is apparent that it is not easy to write good 
documentation, but it IS possible. Not only is it possible to write effective documentation, but it is possible 
to get others to develop the ability to write effective documentation. What they need most is a few simple 
guidelines. 

All Unix users have a good basic documentation mode in front of them every day. Look at the model 
and imagine what more we could do with it. There are excellent tools out there. How should you put them 
together? How could you use them to produce a better result? 

• What are the essential parts of good documentation? 

• How can you avoid endless repetition of the same detail in different types of documentation? (Re¬ 
quirement, Specification, Development, Implementation, Test, User, Support - how much is just cut 
and paste?) 

• How can you get “enough” documentation developed quickly? 

• How can you make it easier to retrofit documentation to those systems that were developed without 
it? 


The Situation 

Motivations 

If you have read the abstract, your mind has probably already moved on from the questions in the abstract 
to several more of your own questions. However, let’s start by establishing a few points of common ground 
which we can build on. 

• Nobody likes waste (especially when they have to pay for it). 

• There is no point in writing documentation if nobody is going to read it. 

• There is no point in writing documentation if the people who will use it have trouble understanding 
it or even have trouble finding what they want in the documentation. 

• Organisations need documentation (because organisations are run by people and people are sometimes 
“unavailable”). 

Having established this (grossly incomplete) list of underlying motivations, and therefore being able to 
begin to direct our choices, what will we choose to do? The most critical thing to capture in a systems 
document is what needs to be done. The second most critical thing to capture in a systems document is 
how to do it. The third most critical thing is why you do it. So we would choose to do at least these things. 
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Diagrams 



The Parts of Good Documentation 

Both from trying to write documentation and from trying to guide others in writing documentation, it is 
apparent that it is not easy to write good documentation, but it IS possible. 

In order to develop this point, we must first identify, or at least characterise, the objective. 

What are the essential parts of good documentation? 

This is an area where opinion outweighs research by Tonnes to Grams. This presentation is really 
opinion based on experience but could not be called research. Experience says the essential parts of good 
documentation are: 

• Simplicity 

• Structure 

• Diagrams 

• Abstraction 


Simplicity could (most simply) be described as “one idea at a time”. Simplicity also addresses the issues 
of keeping the language simple and brief. 

Structure means “give your reader a framework and access points”. Structure operates at two levels - 
information structure and document structure. 

• The framework part of “information structure” is the provision of a description of where the 
information fits in relation to the overall subject and a description of what topics are covered 
in the information. 

• The access part of “information structure” is simply the careful selection of topic names or labels 
that readers can relate to the questions they have when reading the document. “Easy to say, 
hard to do.” 

• The simple document structure “things” which deliver “framework” and “access” to readers are 
chapter and section headings, a table of contents and physical text layout. In larger documents, 
an index is also helpful. Section headings should clearly indicate the topic in that section. The 
section should then stay on the topic. A new topic should indicate the start of a new section. A 
“section” could be as little as a sentence or as much as a whole chapter. This point refers back 
to “Simplicity”. 

Diagrams are an (essential) adjunct to understanding topics and framework. Remembering the cliche “a 
picture is worth a thousand words”, you can convey a large amount with a simple diagram. It is 
also true, that some people understand a visual representation much more quickly and clearly than a 
textual representation the author is one such person. The combination of diagrams and text is even 
more powerful than either on its own. Once again - “Easy to say, hard to do. Particularly hard to 
do well.” 

Abstraction draws the three previous points together. An author must be able to analyse the subject 
and represent it at different levels of detail or layers of abstraction. 

Each level may then be simple while the structure of information and document, represented in text 

and diagram, clearly show how the simple parts fit together. 
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Others Can Do It Too... 

Not only is it possible to write effective documentation, but it is possible to get others to develop the ability 
to write effective documentation. 

Having said that, it doesn’t happen automatically. There are many things which prevent people from 
writing good documentation. In the author’s opinion, the main things which prevent people from succeeding 
at writing good documentation are: 

• Lack of time 

• Lack of analysis and 

• Lack of an appreciation of how much effort is involved. 

However, ... 

• If you can do a job, you can document it. 

• If you can write a program to do a job, you can document it. 

• If you can install a system, you can document it. 

• If you can build a large enterprise information system, you can get someone to document it. 

The issue is - “will it be effective?”. Effectiveness is measured in two domains: 

Information effectiveness is the documentation good at showing how to do or use something and 
does it get used? 

Cost effectiveness - was the cost of developing the documentation proportional to the benefit of having 
it and does it get used? 

Using Guidelines 

What document authors need most is a few simple guidelines. When confronted by the task of writing 
documentation, those who have never done it before could be forgiven for thinking “Well where do I start?” 
Any reasonably competent person can make a start, but, the larger the writing task, the greater the chance 
they will lose the plot somewhere along the way. Some of the common pitfalls are: 

Disappearing into detail - where the author is capturing every detail of the object or procedure they 
are documenting but the reader fell asleep three paragraphs (or chapters) ago, and they still haven’t 
found the bit they need. 

Lack of structure - the information is all there but is not organised in any easily discernable way so the 
reader must scan the whole document looking for what they want. This produces an anaesthetising 
effect on any reader looking for a particular piece of information or technique and discourages them 
from using the documentation because it is just too hard. 

Assumed knowledge that the reader doesn’t have and can’t easily access which renders the document 
useless to anyone but the author (and it can be as simple as what an acronym stands for or where 
something is kept). 

Disconnected information - where what has been written is correct but the reader can’t see where or 
how to apply it. 

The pitfalls can also be physical: 

• The target audience can’t access the document (or related material) - because they don’t know where 
it is or they can’t read the format it is stored in. 

• They can read the document but they can’t take it to where they need to use it because it is only on 
a fixed terminal or terminal type (say, for example, Windows Help) or it can’t be printed and carried 
to the site of operations. 

So if a person starts with a few simple guidelines, can they avoid these pitfalls? The postulation is that 
it is possible to tell or teach people a few simple things which will dramatically increase their chances of 
success. 

The next section looks at what tools are available and makes some suggestions which the author has 
found produce a good result. 
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The Resolution 

The Basics Are All There 

All Unix users have a good basic documentation model in front of them every day. Unix man pages have 
been around for more than 30 years now as a model for how to document technical programs. Even in the 
current environment of browsers and graphical tools, man pages are still often the tool of choice, not least 
because they are right there. You don’t have to lift your hands from the keyboard to access them. 

However, the salient points about man pages which are relevant to this presentation are: 

• They utilise simple tools which are universally available to the target audience. 

• They have a simple regular structure that you can learn and apply to quickly extract content from 
any man page you access. 

• The man pages (and the utilities they document, so long as they adhere to the original model) cover 
one topic well and leave related detail to related pages that handle each of those details well. 

In fact the only limitation of man pages, which was really a limitation of the tools available at the 
time, was the lack of an ability to provide diagrams. But many limitations have now been removed by the 
developments in tools and computing environments over the last couple of decades. 

There Are Excellent Components Available 

There are excellent tools out there. During the last decade or so, a large number of tools have been 
developed or commercialised in the area of document formatting, preparation and presentation. A brief 
list would include: 

HTML and its relatives (XHTML, XML and other markup languages). These languages (used 
for describing formatting in flexible and extensible ways) have their origins in the original Unix 
markup languages (roff, nroff and troff) which in turn came from languages used in the printing 
industry for many years. 

Web Browsers , which provide the ability to display a wide variety of document formats and content 
(including diagrams, pictures, active content and application interfaces) through an interface that is 
common across many different platforms. 

PostScript and PDF. Adobe’s Page Description Language and its variants, which has revolutionised 
many aspects of document preparation, printing and distribution, most particularly (in the context 
of this paper) for its capability to distribute complex content in a relatively small file which can not 
be altered. 

Drawing / Indexing / Authoring Tools. This paper is not a review of these tools, but a few brief 
comparisons for those who have worked in the area amply illustrate the point: 

• Drawing: GEMDraw, pic and eqn compared to Visio2003 

• Indexing: early MSWord and troff / te macros compared to RoboHelp 

• Authoring Tools: early MSWord, SchoolBox and vi compared to RoboHelp 

Of course, there are many other fine tools which might have been used in this list - these just happen 
to be those with which the author has some experience. 

If you have been working in the area over the last 20 years, you will know that document preparation 
and document quality have improved by orders of magnitude in that period, as has the cost of producing 
moderate to high quality documents. 

The advent of hypertext should have led to a revolution in document structure. It is now common to find 
terms defined and related documents accessible through hypertext links and that is a significant benefit. 
However, what doesn’t seem to have changed much is the actual content and structure of documents. It 
still seems to be the monolithic presentation of an entire body of information at a single level of detail. It 
could, and should, rather be a layered presentation which allows and assists the reader to check detail at 
his or her level of need through hyperlinks while allowing a high-level coherent view to those who through 
experience or role don’t need the detail. In simple terms “start at the high level and link to the greater 
levels of detail if you need them”. 

There is a reason why document structure hasn’t yet changed much, but it can and should be overcome. 
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The specific business objective addressed in this document is. 
• Consistent, reproducible quality of goods and services 
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Documentation is an integral part of the organisation's business methods and products 
Documentation records the framework of Requirements. Goals. Designs Methods, Tools. 
Contexts, Project Plans and Defimoons within which the organisation's products and 
services are created and delivered 

The expenence paid for and gained during the creation and operation of business 
activities is captured and preserved by documentation 


Overview: 

i ~his diagram shows the basic document types and the logical relationships between them 



What Could You Do With The Components? 

Look at the model (man pages plus modern extensions) described above and the tools mentioned in the 
previous section and imagine what more we could do with them. 

Just to recap the main points of the model - simple tools, simple structure, each page covers one topic 
well, diagrams, abstraction. How can this be applied to the discipline of systems documentation? In this 
model, the “documentation” is the sum of a large number of small pages which each cover one topic well. 
It is explicitly NOT a monolithic document. How does this sit with the “framework” objective discussed 
earlier? We talked about chapter and section headings but a man page is supposed to be only a couple of 
printed sheets. 

Consider a tool that would allow you to develop HTML pages in a WYSIWYG editor, hyperlink them 
extensively, provide easy tools for maintaining the hyperlinks, provide and maintain a very easy Table 
of Contents function and allow you to distribute an HTML based web “site”, a PDF document or your 
choice of Microsoft formats from the one set of source materials. In this world, your simple, brief “pages” 
have been collected together into a “document”. But it’s much easier to get someone to write a “page” of 
documentation than it is to get them to write a “document”. (And you get something useful much more 
quickly.) 

So, what pages do you need? 

An analysis of the parts or types of system documentation yields the following specific page types which 
need to be delivered to provide “full” documentation of a product or system: 

Definitions (for clarifying exactly what is meant by terms which are used in an organisation specific way) 

Requirement (for specifying the business’s needs and strategies in business terms one page per require¬ 
ment) 

Goal (for quantifying deliverables, targets and expectations for each of the Requirements) 

Design (for establishing the architecture and implementation details of Requirements and their Goals in 
technical terms but related back to the business terms which gave rise to the need for a design) 

Project Plan (for showing how and when designs will be translated into Methods and Tools and linked 
to, or implemented in, Contexts) 

Method (for recording the step-by-step means of completing a task or achieving an objective at a par¬ 
ticular level of abstraction i.e. with a particular level of assumed knowledge a bulleted or numbered 
list of steps) 
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Tool (for describing the specific uses of tools used to execute Methods the tools themselves should already 
have syntax and functional documentation which you can link to.) 

Context (for describing the environment within which Methods and Tools are used a location, a machine, 
a file format, a configuration) 

These page types can be broadly grouped into the Definitions, the Specification Pages (Requirements 
and Goals), the Delivery Pages (Design and Project Plan) and the Operational Pages (Method, Tool and 
Context). You will have many of each page type, one for each topic of a particular type but all linked 
together. For example, you will have one “Requirements” page for each requirement the business has and 
one Method page for each separate task that needs to be done. A high-level Method page may link to 
many layers of more detailed Method pages, but YOU can control how deep you go and when you go there 
it can be demand generated. 

Starting Conditions 

To break your documentation down into these broad page types from the outset is very difficult to do for 
an existing system being retrofitted with documentation. The type of analysis required does not come 
naturally to about 99.999% of the human race. However, there are ways to get in to the process which a 
majority of the human race can do with some degree of comfort. Which of the methods (suggested below) 
you would apply depends on your starting conditions. 

To generally define your starting conditions, there are two primary environment types in a field of 
possibilities whose co-ordinates are graphed along the axes “No Documentation to Full Documentation’ 
and “Product in Development” to “Product is Mature”: 

“No Product and No Documentation” would be your starting condition for a totally new product 
development with documentation created as part of the project. (See the bottom left corner of the chart.) 

“Frill Product and Full Documentation” would generally be the target condition (however “full” docu¬ 
mentation does not necessarily mean “good” documentation so that may force you down into the bottom 
right corner of the graph where most systems sit). 
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That bottom right corner of the graph, characterised as “Full Product and No Documentation” (or 
“No Useful Documentation”) is where an unacceptably large number of IT environments wind up for one 
of two reasons both related to cost (time or money or both): 

• The budget didn’t allow for development of documentation in parallel with the development of the 
product or environment. 

• The budget didn’t allow for maintenance of documentation in parallel with the upgrade / growth / 
relocation of the product or environment. 

An environment (or product) with “No Useful Documentation” usually only works effectively, or at 
least efficiently, for as long as the person or team who built it work there. 

Method 1: No Product / No Documentation 

In this case, you are looking at a situation where you can create the full document set described above in 
the order specified (obviously with some parallelism and looping through iterations of each page type as it 
gets developed and refined). That is: 

• Start with your Definitions and Requirements 

• As the Requirements start to crystallise, more specific Goals can be defined and specified. 

• Once Requirements and Goals are specified, you have enough information to Design a solution. 

• With a Design, you can create a Project Plan to build or implement the Design. 

• As you are building your product or environment, it becomes possible to define the Methods, Tools 
and Contexts which define the product / environment and its operations. 

Remember, as you do this, that abstraction layers are important in making the document useful to 
readers with widely varying skill and knowledge levels. This m eans - 

Make your top level document describe things at a very high level of abstraction that someone very 
knowledgeable in the area could understand. Then, for each time a less knowledgeable person asks the 
question “what does that mean?” or “how do you do that?”, add another document at a lower level of 
abstraction (a higher level of detail) answering the question. If you apply this method recursively, eventually 
you have full documentation. 
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Method 2: Mature Product / No (Useful) Documentation 

The difference in the method for this type of starting condition is in which documents you do first. For 
an existing or mature product or environment, the first and most important question is likely to be “How 
do you do that?” and all the lower level questions like “where is that” Are likely to flow from the initial 
question. Only much later will you get to the questions “what did we really want?” and “why did we do 
that?”. Therefore, your entire initial focus should be on “What do we do?” and “How do we do it?”. Your 
current staff, no matter what they think their level of documentation skill is, can write you a bullet point 
list of what they do. This dictates that the more appropriate order of approaching document development 
for an existing product or environment is: 

1. Focus on pages describing Method, Tools and Context and 

2. retrofit Design pages to document what you’ve got rather than as a specification of what you will 
have. 

When you then get to Upgrade or Replacement projects, you can return to Method 1. That is: 

• Requirements 

• Goals 

• Design (showing how the requirements and goals will now be addressed). 

So, over time, as legacy products and environments with limited documentation grow and get replaced, 
they are replaced with fully documented systems. These systems can be created with documentation at a 
level that the business has consciously decided is the acceptable trade-off between cost and effectiveness. 

If You Combine The Components And The Method? 

Which tools should you select to create this structured documentation? What are you looking for in your 
documentation tools? How should you put the tools together? 

• You are looking for tools which can organise and produce the required components in several formats 
from a single source (because you only want to maintain information in one place if that is possible). 

• You are looking for tools which can automate the generation of distributable copies of the documen¬ 
tation both network / web based and print based distribution. (Consider how you use documentation 
on how to rebuild a system when the system is down and you are in a machine room with no desks 
or connection points you need a separate documentation server or a printed copy or both can you 
generate both?). 

• You are looking for tools which are capable of generating a table of contents / index structure and 
hyperlinks and maintaining them as you add to your documentation. Hyperlink maintenance is a 
particular concern as your document set grows. 

R is up to you to identify tools that meet these criteria, but they do exist and they get better with 
each passing year. But the tools are only enablers - it is what you do with them that is of value. 

You Can Produce An Excellent Result! 

How could you use the tools and the suggested approach to produce a better result? 

How can you avoid endless repetition of the same detail in different types of documentation? (Re¬ 
quirement, Specification, Development, Implementation, Test, User, Support - how much is just cut and 
paste?) 

Use the model suggested above and develop each instance of a page type only once but permanently 
include it in a single complete document. Requirements, Goals and Design should be a permanent part of 
product and environment documentation. You then have the advantage of knowing the business reasons 
behind a design, which can be very useful when you come to update the design. Generations (versions) of 
the Requirements, Goals and Design pages can then document the development or growth of your product 
or environment. 

IIow can you get “enough” documentation developed quickly? How can you make it easier to retrofit 
documentation to those systems that were developed without it? 

These two are really the same question. As suggested in Method 2 above: 
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• Start with Method pages at a high level of abstraction so that experienced people can progress quickly 
and 

• then work your way down into the details (for less experienced staff) over time 

• by just developing a new page of documentation each time a staff member asks “how?” or “where?” 
or “what?” or “why?”... 

For existing systems - Focus on Methods and answer the questions that arise with documents (like: 
where is that?, what is that?, how do you use that?, why do you do that?). As stated above - it’s much 
easier to get someone to write a “page” of documentation than it is to get them to write a “document”. 

But. .. 

It won’t necessarily be fast or cheap, but it will be good... 

And one last suggestion — in technical documentation it is SOOOO much easier to use if you make 
extensive use of bulleted or numbered lists when you are enumerating requirements, goals, steps or any 
other “set” of information. If you write technical documents in pure prose, even deathless prose, it is hard 
to read, hard to evaluate and nearly impossible to update because it is so hard to find anything. 
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Abstract 

PostScript is primarily designed as a device-neutral page layout language to be interpreted by printing 
devices. It is however a complete language with all the usual constructs that more traditional programming 
environments enjoy but differs markedly from more traditional languages in a number of respects. 

In normal use PostScript is very rarely viewed directly by a human - typically an application or driver 
will prepare PostScript code for a printer which is then spooled and executed immediately to form the final 
output. This entire process is completely invisible to the user - only when a problem develops within the 
printer and an error page is emitted does the user glimpse any part of the interpreter which does all the 
work. 

This paper gives a brief introduction to PostScript and how to program effectively in the language. 


Introduction 

History 

PostScript was first written by John Warnock, Chuck Geschke, Doug Brotz, Ed Taft and Bill Paxton. In 
1984 they began the work of constructing the interpreter for a new language which would be able to be 
embedded inside printer hardware and provide a common language for document layout, which they hoped 
would become a de facto standard for the industry. 

At the time most computer-driven printers were line-based and would only print text - more complex 
designs required handset type or line art to be prepared manually before generate the final output. 

Those printers which were able to produce graphics were essentially simple devices which took a binary- 
encoded data stream and transferred it to the page without modification. The task of layout and rasterising 
the page was left to the computer supplying the printer with data. Often, these type-setting and layout 
packages were inordinately complex and very difficult to use creatively. 

Commercial-grade dot-matrix impact printers were also common during the same period. Rather than 
using individual type heads to print a character as was the case with line printers, dot-matrix printers 
stored pre-rasterised images for each glyph and wrote those to the page as they were needed. 

Despite the drop in print quality, dot matrix printers were seen as a great leap forward, since they were 
also capable of printing arbitrary images and text, when given appropriate input. 

In order to switch from text to graphics modes these printers evolved quite complex series of binary 
commands. Unfortunately, they would vary markedly between manufacturers and even between product 
lines from the same company. 

To make matters worse the computing industry had not standardised on any interface model and 
application developers were not able to rely on a standardised API with which to talk to the printer. This 
also had the effect of forcing the end user to be trapped into vendor lock-in. 

Design Principles 

The team at Adobe wanted to create the means to simplify document preparation and printing. From the 
beginning PostScript was designed to take advantage of a vector-based approach for specifying graphical 
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elements as this allowed infinite scaling and smooth curves, something which was impossible with raster- 
based methods without introducing horrible anti-aliasing effects. 

Quite remarkably for a company of the time they decided that the PostScript language specifica¬ 
tions would be openly published to allow anyone to create PostScript drivers for use with Adobe-certified 
PostScript interpreters. Adobe then would focus on writing or certifying the interpreters to read and 
execute PostScript programs which would be licenced by manufacturers and embedded into their printer 
product lines - the first of these manufacturers was Linotype, who licensed the Adobe interpreter for use 
in their industry-grade Linotronic 100 and 300 imagesetters, capable of 1250 and 2540 dpi respectively. 

Adobe had also decided to treat fonts and glyphs in the same manner as any other graphical element 
- fonts were therefore not restricted to any particular form or typography style and could be arbitrarily 
scaled without losing any legibility. To help the adoption of the technology, Adobe licensed a the Helvetica 
and Times fonts from Linotype to be embedded as standard fonts with all PostScript interpreters, which 
is the main reason they are now so widespread. 

It wasn’t until Apple began building their LaserWriter range of printers that Adobe found a ready 
consumer market and things began to take off there as well. Once the LaserWriter became popular, small 
business and home users were able to produce all their documents in-house with nothing more than page 
layout software such as Aldus PageMaker, a Macintosh and a PostScript printer. 

Consumer Implementations 

Early consumer laser printers were 300dpi but only contained enough memory to hold a small band of 
device-ready rastered output. In order to get around this problem the interpreter was designed to store all 
the vectors which made up the page and then rasterise them a chunk at a time when the laser engine was 
ready to commit it to the page. 

This complexity meant that the PostScript printers were a good deal more expensive than other laser 
printers such as those from HP who had continued with variations of the binary-encoded data format they 
had used with their original dot-matrix printer products. 

PostScript was gaining further acceptance in the industrial printing and desktop publishing market 
however. It’s greatest strength for these markets was the ability for a publisher or author to create a work 
and proof it using a commercial grade 300dpi PostSript printer knowing that the final photo-ready copy 
would be set using an industrial grade PostScript printer which would reproduce the page exactly as the 
author intended. 

Because of its flexibility, variations of PostScript have also worked their way into other areas: 

Display PostScript 

A variant of the language called Display PostScript (DPS) was integrated into some commercial Unix 
XI1 servers for CAD work. This is a specialised, binary only version of PostScript which was used 
to provide a GUI layer between an application and a display. 

Among other things it allows windows to be scaled and rotated to any angle with the application 
none the wiser, since all buttons and other graphical elements scale along with the window. DPS 
makes sure that no matter where a button ends up, a button event makes it back to the application 
when it is clicked. 

Unfortunately for Adobe, DPS failed to catch on for some time, although Apple has recently begun 
to use a more up-to-date version of this technology in their Mac OSX windowing environment. 

Portable Document Format 

Adobe’s Portable Document Format (PDF) is also heavily based on PostScript - like DPS, PDF is a 
binary-oriented PostScript stream with extra emphasis placed on metadata. 

PDF is primarily used to transmit print-ready documents to the end user. This even works in cases 
where the end user does not have the application which was used to create it but they can still 
produce an exact copy of the output on their local printer. 

Often PDF documents can be set up to allow modification by the end user and returned for sub¬ 
mission. This allows PDF documents to behave more like web pages and multimedia sessions with 
support for internal linking, web forms and so on. 

Large PDF documents can also be tailored for slow network connections since the format allows for 
readers to jump to discrete points within the stream without needing to download the content in 
between. 
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In the same manner that application running on a local host could produce a PostScript file for a 
local printer, it is now common for a remote database-driven web server application to produce a 
PDF on the fly with the appropriate information in it which is then printed locally by the user. 


The PostScript Interpreter 

PostScript interpreters are found in a wide variety of configurations and hardware. 


Commercial Interpreters 

Perhaps the most common commercial implementation of the PostScript interpreter can be found embedded 
in the majority of mid- to high-end printers and RIP engines. 

Because of the embedded nature of these interpreters they can be hard to uncover and interact with, 
short of sending them a file and running batch mode. 

Most printer models these days will support the JetDirect protocol over TCP/IP, available via port 
9100. All PostScript interpreters should support the executive operator, which will allow you to talk to 
them directly as in Figure 1. 

auqakuh[~] lv'/,: telnet hp4000 9100 
Trying x.x.x.x... 

Connected to hp4000. 

Escape character is *“] *. 

7. IPS-Adobe-1.0 
executive 

Copyright (c) Hewlett-Packard Company, 1997 

Version 2014.108 

PS> 


PS>quit 

~D 

telnet> quit 
Connection closed, 
auqakuh [~] 2v7.: 


Figure 1: Example JetDirect session, showing how to invoke the embedded interpreter in an HP4000 
printer. 

Using the interpreter in this way has the advantage that you are able to test code on an Adobe-certified 
interpreter, however the downside is that the printer is generally unavailable to spool other jobs whilst 

Other commercial PostScript interpreters include Adobe’s own Acrobat Distiller, which takes PostScript 
output from a variety of sources and produces PDF files. Distiller can be used to generate PDFs from almost 
any source of PostScript without problem. Unfortunately Distiller is not able to be used interactively as it 
is run purely as a batch process. 

Open-Source Interpreters 

GhostScript by Aladdin is the most popular and integrated Open-Source PostScript interpreter, gs is 
available for many platforms and is able to produce rendered output in a wide variety of binary formats 
- it is most often used by the Common Unix Printing System project (CUPS) to provide binary output 
suitable for non-PostScript printers. 

gs by itself does not have a particularly useful user interface - this is better supplied by programs 
such as gv. gv provides scaling, zooming and other transformations on the rendered output from the one 
interface and uses gs behind the scenes to read the PostScript files and provide the rendered output. 

As with Adobe Distiller, gs is able to produce PDF files from PostScript input. This has the advantage 
that a license fee does not need to be paid to Adobe, however the finished output may not be quite 
compatable with some PDF readers although this is quite rare. 

In general, gs is easy to use and very useful for testing and debugging code. Because the interpreter 
itself is not Adobe-certified it may not be completely compatable with some PostScript input, but on the 
whole an interpreter running on a fully fledged Operating System will have access to more resources and 
memory than one running as an embedded program. 
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Simple Graphics Programming 

Initial Graphics State 

When a PostScript program first begins, the interpreter can be relied upon to be set up with a standard 
graphical environment, regardless of the hardware used to put the image onto paper. 

In this environment, the coordinate system is measured in 1 /72 inch units, called points. The origin 
is at the bottom left corner of the page, which is probably outside the printable area. The clip path 
determines the area which can be marked and this is set to bound the maximum area that the printer can 
print to. 

By default the page is in portrait orientation, with positive values of X and Y moving the pointer to 
the right and up respectively. The default line width is one point and the default colour is black. There is 
no font defined initially. 

It is very simple to draw in this environment, as seen in Figure 2. 


'/.IPS- Adobe-1.0 

'/. 28pt is roughly 1cm 

0 setgray 

28 28 moveto 
56 28 lineto 
56 56 lineto 
28 56 lineto 
closepath 
stroke 

showpage 


Figure 2: Simple hard-coded box 

Unfortunately our code here isn’t particularly well suited for reuse, so let’s try that again and define 
the box-drawing portion as a procedure, as in Figure 3. Note here that we need to pull the arguments for 
the box procedure off the stack in the reverse order that they were added. Each argument is given its own 
variable to live in and make our code easier to read. 


'/.IPS-Adobe-1.0 

/box { '/. llx lly urx ury => — 

/ury exch def 
/urx exch def 
/lly exch def 
/llx exch def 

llx lly moveto 
urx lly lineto 
urx ury lineto 
llx ury lineto 
closepath stroke 

} def 

28 28 56 56 box 
showpage 


Figure 3: Simple procedure-based box 

We may have chosen to specify our box in terms of its width and height rather than its bounding 
corners. Figure 4 shows this and another method for reading procedure arguments from the stack. 

Remembering individual page coordinates in terms of PostScript points is going to get stale very quickly 
- it may make more sense to specify them in terms of real lengths such as millimetres or inches. It is very 
easy to define small procedures which take a value in one unit and return the result in PostScript points, 
as in Figure 5. 
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7. IPS-Adobe-1.0 

/rbox { / llx lly width height ==> — 

[ /height /width /lly /llx ] { 
exch def 
} forall 

llx lly moveto 
width 0 rlineto 
0 height rlineto 
width neg 0 rlineto 
closepath stroke 

y def 

28 28 28 28 rbox 
showpage 


Figure 4: Simple relative procedure-based box 

/pt { 1.0 mul } def 
/m { 283.46456 mul > def 
/cm ■[ 28.346456 mul }- def 
/mm { 2.8346456 mul > def 
/in { 72 mul } def 

100 setrgbcolor 
0.5 in 0.5 in 1 in 1 in rbox 

010 setrgbcolor 
1 mm setlinewidth 
1 cm 2.5 cm 25 mm 1 cm rbox 


Figure 5: Unit procedures (rbox definition not shown). 



Transformations 

We don’t have to stick with our default coordinate system if we would prefer to use something else. 
PostScript allows the user coordinate system to be changed in almost any way with a combination of 
translation, rotation, scaling and shear, as in Figure 6. 

Rather than creating procedures to convert between arbitrary coordinate systems to PostScript points, 
it is very simple to set the graphics state to make such conversions automatic. 

For instance, if an application requires that line segments be drawn in centimetre units, a simple scaling 
is all that is necessary, such as 1 cm 1 cm scale. Thereafter, a line such as 10 10 moveto 15 10 lineto 
stroke would be 5cm long and set 10cm from the bottom and left edges of the page. 


Painting 

Once the path we want to draw is constructed, we need to tell the interpreter to commit the marks to 
memory and either fill the described shape or trace its outline. This is done simply with the fill or 
stroke operators, as in Figure 7. 

fill uses the current colour and fill pattern (not described here) and will use that to paint the area 
enclosed by the current path, stroke takes the current colour and dash pattern and uses those to trace 
the sections of the path which were produced with the lineto operator. 

When preparing a path to be painted it is always a very good idea to use the closepath operator to 
make sure that the interpreter knows the proper boundary for the fill or that the two end points of the 
line need to be drawn as an intersection and not with line end caps - it is not enough to make sure that 
the end points are at the same position on the page. 

gsave and grestore can also be used to good effect with painting as well - each time a fill or stroke 
operator runs, the current path is cleared. For example, if an application wanted to fill a shape and trace 






AN INTRODUCTION TO POSTSCRIPT 

/cmbox { 0 0 1 cm 1 cm rbox > def 

0 setgray cmbox 

2 cm 2 cm translate 

001 setrgbcolor cmbox 

1.5 1.5 scale 

010 setrgbcolor cmbox 

30 rotate 

100 setrgbcolor cmbox 



Figure 6: Transform example 

/rboxpath { 

10 0 rlineto 0 10 rlineto 
-10 0 rlineto closepath 
} def 

1 mm 1 mm scale 

10 10 moveto rboxpath 
010 setrgbcolor 
stroke 

30 10 moveto rboxpath 
100 setrgbcolor 
fill 


Figure 7: Painting example 


its outline with a line the path bordering the shape would need to be drawn twice without some means 
to save it. Instead, the path can be saved, filled, then restored and traced with code such as gsave 0.5 
setgray fill grestore stroke. 

Clipping 

PostScript allows the programmer to specify a boundary beyond which the interpreter will not make any 
marks on the page. Initially the clip path traces the maximum area that the printer can print to. 

New clip paths can be set at any time, however the resulting clipped region is defined as the intersection 
of the current clip region and the new one. 

The upshot of this is that the clip region may shrink but never grow - if a bigger area is needed then 
initclip needs to be called to set it back to the default. This is shown in Figure 8. 



‘/.IPS-Adobe-1.0 
5 mm 5 mm scale 
tiles 

0.5 0.5 moveto 5 9.5 lineto 9.5 0.5 lineto 
closepath clip newpath 

0.5 setgray 
tiles 

showpage 


Figure 8: Clipping example 
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As with other graphic state changes, clip boundary settings can be controlled with appropriate uses of 
the gsave and grestore operators. 

The initial clip path can be used to give an idea of the size of the page in conjunction with the pathbbox 
operator, pathbbox takes the current path and returns the coordinates of the lower left and upper right 
corners of the smallest box which will fit the path. The code in Figure 9 gives an example of this. 

.. "" '/.IPS Adobo-1 .0 

7, outlines the current clip path bounding box 
clippath pathbbox 

[ /ury /urx /lly /llx ] { exch def > forall 

newpath 

llx lly moveto 
urx lly lineto 
urx ury lineto 
llx ury lineto 
closepath stroke 


showpage 


Figure 9: pathbbox example 


Saving Graphics State 

Having performed all the transforms to the graphics state to better suit our application it can be quite 
frustrating to have to set it all up again because of the actions of some PostScript operators. 

For example, the showpage operator is used to tell the interpreter to send the page-ready data to the 
print engine. As part of its function, showpage also clears the page memory and resets the graphics state 
back to the default. 

Fortunately, PostScript offers a simple remedy to the problem - the interpreter can be told to keep a 
copy of the graphics state in memory for later restoration with the gsave and grestore operators. These 
are often seen in action together to bracket a showpage operator as in gsave showpage grestore. 

As with many other things in PostScript, the gsave and grestore operators function to make the 
graphics state look like a stack - each save operation can be restored only by working backwards through 
the saved states. In PostScript Level 2 this is relaxed somewhat with the introduction of operators to save 
and load graphics states directly, providing a useful shortcut in some cases. 

Colour 

Colour is very important in the printing process. PostScript has a number of different ways of being able 
to specify colour values, each tailored for use on different sorts of printing processes. Any of them can 
be used on an interpreter that supports colour, in keeping with the device-neutral approach taken in the 
design of the language. 

Possibly the most used colour space would be black and white, since most printed material consists of 
black text on a white background. The set gray operator is used to set a shade from 0.0 (full black) to 1.0 
(full white). Values outside this range are mapped to their nearest valid value, setgray is available on all 
PostScript interpreters. 

Greyscales are fairly easy to encapsulate in a single number, but full colour is a little more tricky. For 
users used to a graphical approach to colour the setrgbcolor operator is probably most familiar. This 
operator takes three individual values for red, green and blue and uses those to set the colour value. Like 
setgray, setrgbcolor colour values range from 0.0 (black) to 1.0 (full colour). 

For more specialised users there is also the ability to set colour values by specifying the hue, saturation 
and brightness with sethsbcolor. Here, saturation and brightness operate in a similar mann er to the 
colour specification for setrgbcolor however while the hue value remains valid only from 0.0 to 1.0 it 
is interpreted as an angle around a colour wheel with 0.0 and 1.0 both being red. Green and blue are 
represented as 0.33 and 0.66 respectively. 

The printing world is probably more interested in setting colour values in terms of cyan, magenta, 
yellow and black - this is done with the setcmykcolor operator. Like the setrgbcolor and sethsbcolor 
operators, setcmykcolor values are represented as 0.0 (no colour) and 1.0 (full colour). 
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An example of these colour operators is given in Figure 10. 



'/.! PS-Adobe-l. 0 

/cw 50 def /ch 16 def 

/ox 0.5 cm def /oy 0.5 cm def 
/w 4.0 cm def /h 4.0 cm def 
/pw w cw div def /ph w ch div def 

/draw { 

ph mul oy add moveto 
0 ph rlineto stroke 
> def 

pw 1.1 mul setlinewidth 
0.0 1.0 cw div 1.0 { 


/i exch def 

/x ox w i mul add def 

i 0 0 0 setcmykcolor x 13 draw 
0 i 0 0 setcmykcolor x 12 draw 
0 0 i 0 setcmykcolor x 11 draw 
0 0 0 i setcmykcolor x 10 draw 

ill sethsbcolor x 8 draw 
Oil sethsbcolor x 7 draw 
0 0 i sethsbcolor x 6 draw 


i 0 0 setrgbcolor x 4 draw 
0 i 0 setrgbcolor x 3 draw 
0 0 i setrgbcolor x 2 draw 

i setgray x 0 draw 


> for 


showpage 


Figure 10: PostScript colour operators: setgray, setrgbcolor, sethsbcolor and setcmykcolor 

There are more advanced treatments of colour available within the PostScript interpreter, such as colour 
spaces and colour seperation printing, however these are not covered in this text - the operators above will 
provide most if not all of the required functionality. 


Fonts And Text 

Printing text is probably the most often required function of a language such as PostScript. From the 
beginning PostScript was designed to treat font glyphs in the same manner as any other graphical element, 
but since then features have been added to the language to speed up the rendering process. 

Font glyphs in PostScript can be defined in terms of pre-rastered bitmaps (Type 1) or discrete paths 
made up of curves and straight segments (Type 2) or a combination of both (Type 3). Usually Type 2 fonts 
are preferred as these can be scaled arbitrarily or used to provide other graphical effects such as outlines 
or used as a clip boundary, for example. 

PostScript interpreters generally have a selection of fonts available to them, however they often differ 
between manufacturer and printer model. Fonts which are most likely to be present in any environment 
are Helvetica, Times and Courier. 

PostScript does allow some fonts to be known by more than one name inside the printer - this is most 
often seen in cases where the font which is available has very similar characteristics to the requested one 
and can be substituted without too much error. 

If a program asks for a font which is not available, Courier is generally used instead with often quite ugly 
results - this can be alleviated by downloading the font definitions with a print job if you are experienceing 
this problem. 

In terms of coding in PostScript, selecting a font is fairly straightforward: the findfont operator is 
asked to locate the font definition and load it onto the stack as a font dictionary, scalefont is then used 
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to set the font to the correct size. At this point the font dictionary can be saved for later use or made the 
current font immediately with setfont. 

Once the font is selected the text itself needs to be placed on the page. The current point is set to the 
beginning of the line of text and the text is handed to show as a string, show is set up to leave the current 
point at the end of the previous string, so if another section of text needs to be added it can be simply 
called again. 

A simple Hello World! example is given Figure 11. 


•/.!PS-Adobe-1.0 

/Helvetica findfont 
0.5 cm scalefont setfont 

1 cm 1 cm moveto 
(Hello) show 
( ) show 
(World!) show 

showpage 

Hello World! 


Figure 11: Simple Hello World! example 


show is fairly simplistic in the manner in which it lays out text and does no kerning or other tricks 
to make the string look better laid out - these are better provided by other variants of the show operator 
which are not covered here. 

The stringwidth operator can be used to determine the width of a string if it were to be placed on the 
page in the current font. This can be used to create a simplistic text layout program, as given in Figure 12. 


Lorem ipsum 
dolor sit amet, 
consectetuer 
adipiscing elit. 
Duis rutrum dui 
ut neque. 


7,! PS-Adobe-1.0 
/text [ 

(Lorem) (ipsum) (dolor) (sit) (amet,) 
(consectetuer) (adipiscing) (elit.) 

(Duis) (rutrum) (dui) (ut) (neque.) 

] def 

/Helvetica findfont 15 scalefont setfont 
0.5 cm 4.0 cm moveto gsave 

/total 0 def /space ( ) stringwidth pop def 
text { 

/word exch def 

/width word stringwidth pop def 

total width add space add 4.0 cm ge { 
grestore 0-15 rmoveto gsave 
/total 0 def 
> { 

( ) show /total total space add def 
} ifelse 

word show 

/total total width add def 
> forall 

showpage 


Figure 12: Simple layout example 
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PostScript Types 

Previously we haven’t gone into the specifics of the various types of objects that PostScript can manipulate. 
PostScript has a rich range of object types to represent various types of data. 

Stack items are regarded as either simple or complex, depending on whether the data they contain 
requires any extra memory - integers and reals do not require any extra storage and are simply stored on 
the stack. 

Other items, such as strings, arrays, procedures and dictionaries store their data in main memory and 
these objects are used to refer to them - the data for these is manipulated indirectly through pointers. 

Usually the difference isn’t noticable, however there are instances where these properties can be exploited 
to good effect. 


Numbers 

Numbers may be real or integer within PostScript. Real numbers use the usual decimal or exponent form 
(eg, 123.4e5). 

There is also the radix number form, which allows specifying numbers of different base, usually used 
for binary (2#10010), octal (8#7732) and hexidecimal (16#FFFE). 

Strings 

Strings are specified by three methods: 

• As literal text enclosed between ( and ) (eg, (hello)) 

• As hexadecimal data enclosed between < and > (eg, <DEADBEEF>) 

• As ASCII-85 encoded data enclosed between < and > (Level 2 only) 

For literal text, the following C-like escape sequences are supported: n, r, t, b, f and backslash. 
Brackets must be escaped if they are not to be interpreted as the end or beginning of a string. Octal 
numbers may be represented by a backslash followed by three digits. 

Linefeeds within strings may be escaped with backslash at the end of the line, otherwise they are treated 
as n. If a backslash precedes a character that is not part of the list above, it is ignored. 

For hexadecimal data, the one catch to be wary of is having an odd number of digits in the string. 
For instance, <901FA3E> is properly formed, however <901FAE> would be interpreted as a string with the 
hexadecimal characters 0x90, OxlF and OxOA. 

Names 

Any token that cannot be interpreted as a number will be treated as a name object. Name objects may 
contain any character apart from spaces and other delimiters (eg brackets, < and >, 7«). This means that 
punctuation may also be used in names (eg @, ., #, and $ are all valid name characters). 

Take care when choosing names that look like numbers in either the real or radix form - 23A1 is a valid 
name, however 23E1 is interpreted as a real, and 23# 1 as a radix number. 

A name may be prepended with a / character to indicate that what follows is a literal name. Names 
that begin with // are termed immediately evaluated names. 

Arrays 

Arrays are delimited by the [ and ] characters. Each token after the first [ is parsed and executed one at 
a time until the last ] is encountered, at which point the complete array is constructed and placed on the 
operand stack. 

Arrays may also be created with the array operator. 

Procedures 

Procedures are delimited by the { and } characters. 

In essence, procedures are merely executable arrays, however they are constructed quite differently. 
Whereas the simple array is evaluated element for element until the final ] is encountered, procedure 
content is essentially treated as literal data until the final } is found. 
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Whilst constructing a procedure, the interpreter pushes elements onto the operand stack, but does not 
execute them. Once the } is encountered, the array is constructed then marked as executable and pushed 
back onto the operand stack. 

Dictionaries 

Dictionaries are one of the most fundamental constructs of the PostScript language. Dictionaries are similar 
to Perl’s hashes in that each element in a dictionary has a name and a value, and individual items can be 
retrieved from a dictionary by their name. 

Dictionaries may be created with either the diet operator or « or » marks. 

Miscellaneous Objects 

There are several other PostScipt object types which fill out the language, although numbers, strings, 
names, arrays and dictionaries are probably the most important. Some of these are: 

boolean 

The values true and false, 
mark 

The mark object is used primarily for array and dictionary construction ([ and « merely place a 
mark object on the operand stack). 

save 

This object type is used as a token for memory states. 

file 

Any filestream that the interpreter has access to can be accessed through these. 


Interpreter Environment 

As mentioned earlier, PostScript is a stack-based language. Most of the operations undertaken by PostScript 
programs are concerned with the operand and dictionary stacks, however so far we’ve not needed to know 
much about them. 

Operand Stack 

The operand stack is the main stack used by PostScript programs to perform operations. Items are pushed 
onto the operand stack in the correct order, operators are invoked to manipulate them, then the results 
are pushed back onto the operand stack. 

The operand stack may hold any object type. The total number of items the operand stack may hold 
depends on the implementation of the interpreter. 

Dictionary Stack 

The dictionary stack is quite different from the operand stack and is mainly used for looking up the values 
of defined names. 

Dictionaries can be created and manipulated on the operand stack as any other object is, but the begin 
and end operators are used to push and pop individual dictionaries onto and off the dictionary stack. 

PostScript Name Resolution 

When the interpreter finds a name object to execute, it first looks for the relevant value in the uppermost 
dictionary on the dictionary stack. If it finds the appropriate entry, the value is pushed onto the operand 
stack and executed. 

If the uppermost dictionary does not contain a value to match the required name, the interpreter will 
consult the dictionary further down the stack until the name is resolved or the dictionary stack is exhausted, 
in which case the interpreter returns with an error. 

The interpreter may look up names in the dictionary stack at several points when parsing a PostScript 
program, depending on the type of name being resolved: 
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literal names 

Literal names are not resolved by the interpreter, but are passed to the stack without modification. 
Literal names begin with /. 

executable names 

Any name object which is not literal is searched for from the top of the dictionary stack. If the 
interpreter is constructing a procedure, the name lookup is deferred. 

immediately evaluated names 

These names are looked up and resolved from the dictionary stack as soon as they are encountered 
by the interpreter, regardless of whether a procedure is being constructed. Immediately evaluated 
names begin with //. 


Simple Programming 

What follows are a number of worked examples to illustrate how the language works. They are by no 
means complete, but should show enough by themselves to get you going - for more detail consult the 
PostScript tutorial books mentioned in the References section. 

Text Output 

Although not often useful in the case of an interpreter embedded in a printer, PostScript does have a 
number of operators which can produce text output as listed in Figure 13 - these are most useful when 
using gs or gv. 


'/.IPS-Adobe-1.0 
(simple printing\n) print 
(\nwithout interpretation:\n) print 
1 = 

(one) = 

[12 3] = 

/too = 

1 diet = 

(\nwith interpretation:\n) print 

1 == 

(one) == 

[ 123 ]== 

/foo == 

1 diet == 

'/, *only forms: 

(\n*only forms:\n) print 

(blah) =only 
(blah) ==only 

(\n) print 


simple printing 

without interpretation: 
1 

one 

—nostringval— 
foo 

—nostringval— 

with interpretation: 

1 

(one) 

[1 2 3] 

/foo 

-dict- 

*only forms: 
blah(blah) 


Figure 13: PostScript text output operators and output 


Defining Variables 

PostScript variables are held as key-value pairs within hashes, known as dictionaries. In order to create a 
definition within the current dictionary, use the def operator, as in Figure 14. 

Note that /foo and foo are different - in the first case the interpreter treats it as a name literal and 
simply pushes it straight to the stack - in the second case the name is searched for and its value is placed 
on the stack. 

Dictionaries can be created in two main ways, as given in Figure 15. 
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/foo /bar def 
/one 1 def 
/two 2.0 def 
/blah (foo) def 
/flag true def 

/count 0 def 

/count count 1 add def 


/quux { 

(quux\n) print 
}■ def 

/stuff [ 

0 1 (two) true false 
] def 


Figure 14: 

/bag 10 diet def 
bag begin 
/one 1 def 
/two 2.0 def 
end 

/port 10 diet def 
port /one 1 put 


Some example variable definitions 

port /two 2.0 put 

/trunk << 

/one 1 
/two 2.0 
» def 


Figure 15: Some example dictionary definitions 


Logic And Relational Operators 

PostScript support a boolean type (true and false) and has several operators which provide the usual 
sort of logic functions, which are and, or, not and xor. not takes a single boolean argument while all the 
others take two. 

Strings and numbers can be compared using eq, ne, It, le, gt and ge. Note that stack items are 
compared deepest first. This means that if you have pushed 3 and then 1 to the stack, gt will return true. 

Note that some tests on complex objects won’t work as intended - this is because these are represented 
on the stack as pointers to their data in memory - testing their equality can only tell you whether they are 
pointing at the same data. This is illustrated in Figure 16. 

/stringl (blah) def string equality: true 

/string2 (blah) def array equality: false 

pointer equality: true 

(string equality: ) print 
stringl string2 eq == 

/arrayl [123] def 
/array2 [123] def 

(array equality: ) print 
arrayl array2 eq == 

/dictl « » def 
/dict2 dictl def 

(pointer equality: ) print 
dictl dict2 eq == 


Figure 16: Testing complex objects 


Looping 

PostScript supports a number of types of loop constructs, as given in Figure 17. for and f orall will both 
place the current value on the stack before running the code inside the loop, repeat and loop do not do 
this and other arrangements need to be made to achieve the same effect. 

Program Flow 

As with other languages, PostScript has operators to support if-then and if-then-else type constructs. 
Common forms for these are given in Figure 18. 
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0 1 10 { = } for 

[0123456789 10] {==} forall 

/i 0 def 
10 { 

/i i 1 add def 
} repeat 


/i 0 def 
i = 

/i i 1 add def 
i 10 gt { exit > if 
> loop 


Figure 17: PostScript looping operator examples 


blah { 

(blah\n) print 

> if 

foo { 

(was true\n) print 

> -t 

(was false\n) print 

> ifelse 


foo { 

(foo was true\n) print 
> { 
bar { 

(bar was true\n) print 
> if 

} ifelse 


Figure 18: PostScript control operator examples 


Case or switch statements can be made with the loop operator - the loop is terminated at any exit 
operator found, as in Figure 19. 


testl { 

(test 1 was true\n) print 
exit 

> if 

test2 { 

(test 2 was true, and ) print 

> if 

test3 {. 

(test 3 was true\n) print 
exit 

> if 

(default code\n) print 
exit 

> loop 


Figure 19: loop used as a switch statement 


Development Environment 


Programming in PostScript has much the same requirements as any other language for generating useful 
code - any editor will be capable of modifying PostScript files, although an editor such as vim which is 
capable of syntax highlighting are very useful. Software management needs are easily met with something 
like RCS or CVS. 

In order to run and test your code you will need to choose whether you need to view graphical output 
or not. gs is better suited to cases where you are interested in tracking fatal errors and gv is more suited 
to checking presentation or other graphical problems. 
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Using gs 

As with the embedded interpreter in the HP mentioned earlier, you can interact with gs directly from the 
command line, as in Figure 20. 

auqakuh [~] lv'/,: gs 

AFPL Ghostscript 8.00 (2002-11-21) 

Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. 

This software comes with NO WARRANTY: see the file PUBLIC for details. 

GS>quit 


Figure 20: Example GhostScript session (the XI1 window for rendered output is not shown). 

Usually it is easier to create a small shell script to start gs for you with the appropriate arguments, as 
in Figure 21. 

#!/bin/sh 

exec gs -I . -I ./lib -I $H0ME/lib/ps -sDEVICE=nullpage -sPAPERSIZE=a4 


Figure 21: Example script shim to run gs without a display. 

In this example -sDEVICE=nullpage tells gs to use the null device which allows all painting operators 
to work without producing any output. The nullpage device will set the page dimensions to zero, so by 
explicitly using the -sPAPERSIZE=a4 argument this is no longer a problem. Directories that the interpreter 
is to search for files to run are given with the -I option. 

Key-value pairs that are supplied to gs with the -skey=value and -dkey=value flags are available to 
PostScript code as well, which is a very useful way to change program behaviour without modifying code. 

There are subtle differences between -s and -d: the -s option will define a PostScript string with 
the value given (which may then contain spaces); -d will define any other type, depending on the value 
presented - eg, a real if run as -dNumber=3.0. If no value is given, then the variable is defined with the 
boolean value true. 

Using gv 

Unfortunately gv doesn’t offer any method to pass command-line arguments directly to the underlying 
interpreter. Instead these arguments may be supplied by opening the GhostScript Options window 
from the State menu and modifying the values in the Arguments text box. 

These arguments are exactly the same form as given above. 

Advanced gs Scripting 

In certain situations it may be useful to have PostScript code operate as much like a shell script as possible. 
Unfortunately gs can’t be coerced into skipping the Unix #! shell syntax without some help. Figures 22 
and 23 illustrate how to go about it. 

In these examples, gs is told on the command line to load the init .ps file, init .ps in turn contains 
a procedure definition for #! (which is a legal PostScript name). 

When gs opens the shell script again to interpret it as PostScript, the first token it parses will be #!. 
As there is a valid definition for #! it is run and will then consume the input until it finds '/,! as the first 
thing on a line which marks the beginning of valid PostScript code. 

As the interpreter is now set to skip all sh input, we use this space to define a few environment variables 
for neatness. Here it is to see how to select between different output devices by swapping variable definitions 
about. 

File Format 

PostScript files are generally plain-text encoded rather than binary. This allows for greater portability, since 
there is no need to be concerned about escaping dangerous characters when moving or copying PostScript 
data around a network. 
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#!/bin/sh 

RES="-gl536xl024 -rl44xl44" 

RES="-g768x512 -r72x72" 

DEV="-sDEVICE=nullpage" 

DEV="-sDEVICE=pngl6m -sOutputFile=output.png" 

DEV="-sDEVICE=xll" 

QUIET="" 

QUIET="-q -dNOPAUSE" 

LIBS="-I. -I./lib -I$HOME/lib/ps" 

exec gs $LIBS $QUIET $RES $DEV "$@" -c ’(init.ps) runlibfile’ -f $0 
7.! PS-Adobe-1.0 
7. code here 


Figure 22: Example shell code to allow gs to work with the Unix shell #! comments. 


'/.IPS-Adobe-1.0 

7. skip input until you get to 7.! at the beginning of a line 
/#! { 

{ currentfile 1024 string readline } stopped { 

(7.!) anchorsearch { pop pop pop exit } { pop pop }• if else 
> { 

(7.0 anchorsearch { pop pop exit }■ { pop } if else 

> { 

pop exit 
> ifelse 
} ifelse 
} loop 

> def 


Figure 23: Example PostScript code to allow gs to ignore #! comments and shell code. 


Lines of text are usually kept to below 80 characters, but there is no hard limit on this since PostScript 
places no significance on file layout - linefeeds and carriage returns are treated in exactly the same way as 
tabs and spaces. 

Commenting PostScript code is supported and encouraged - any text following after an unprotected 
percent mark ('/») is ignored. 

Traditionally, PostScript files have begun with the magic 7,! string to identify them. Strings immedi¬ 
ately following the 7.! mark are used to denote which form of PostScript follows - without one, PostScript 
level 1 is assumed. 

Adobe have also defined a set of comments that are placed within PostScript files known as the Docu¬ 
ment Structuring Convention. These are used to denote where procedures are defined, page environment 
is set up and where each individual page begins and ends. 

DSC comments are primarily aimed at allowing print spool engines to choose the best printer to handle 
the PostScript file. Other specialist functions can also be managed, such as printing pages in reverse or 
discrete orders, and printing in 2-up or duplex modes. These comments are discussed in more depth in the 
PostScript Language Reference Manual. 
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Language References 

Apart from the references given below, I would recommend having a look through the Adobe site for more 
information on PostScript language programming. Most University libraries also have a few books on 
PostScript if you have access to them. 

Have a good look around for the PostScript operator guide which should be available from somewhere 
on the site (this is essentially a PDF version of the operator summary given in the Language Reference 
Manual) - it is a very very useful thing to have around whilst programming. 

The PostScript Language Tutorial and Cookbook has a number of well commented examples showing 
how the language works. There are electronic copies of these programs available on the Adobe site, and 
give a good grounding in the language. 

There are also a large number of tutorials on the web and in newsgroups. The newsgroup alt.lang.postscript 
generally has an up-to-date FAQ for resources, hints and tips. 

Language Reference 

Adobe Systems Incorportated, PostScript Language Reference Manual, 2nd Edition, Addison-Wesley, 
1990 ISBN 0-201-18127-4 

Language Tutorial 

Adobe Systems Incorportated, PostScript Language Tutorial and Cookbook, Addison-Wesley, 1985 
ISBN 0-201-10179-3 
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Stopping Spammers’ Harvesters 
using a HTTP-tar pit - Details on 
implementation and a real-world 
experiment 


Tobias Eggendorfer 
auugQtobiase. de 


Motivation 


Unsolicited commercial emails, also known as spam, make up for the biggest percentage of emails sent. To 
get rid of the huge amounts of spam, most users try to move spam out of their inbox by using different 
filtering approaches. 


But spam filters are unreliable by technology: All currently known approaches use heuristics to identify 
spam. Thus, they only return the probability of a message being spam, but they are unable to determine it 
with certainty. Current spam filters have a false negative rate, i.e. the amount of spam mails not considered 
to be spam, of less than one percent, which is prone to increase, as spammers test their mailings against 
current filters before sending them out. So spammers are always one step ahead of filtering technology. 

Not only is there a growing false negative rate, but a to high false positive rate too. A false positive is a 
ham-mail, as the opposite of spam is called, declared to be spam. This happens due to to aggressive black 
lists or overeager content filters. But using less aggressive filtering would again increase the false negative 
rate. This turns out to be a vicious circle making filtering inefficient. 


To put it brief. Spam filtering and Anti-Spam-Legislation are only a symptomatic cures. They do not 
resolve the cause. Spam filtering is a reactive technology: So spam filters are always one step behind - the 
same problem as with virus scanners and the main reason why modern worms and trojans keep propagating 
through the internet. 


Anti Spam-Legislation increases the financial risk of a spammer, if they are identified. But they are 
learning to hide themselves in the internet using bot-nets, either installed by their own trojans and worm 
or available for rent. 


Harvesters 

So true preventive solutions are needed: The goal is to stop spam before it reaches a mail server. One way 
to do so without reworking the SMTP is to try to not give mail-addresses to spammers. There are many 
ways, spammers get mail addresses, some of them are described in [1] [2] and [3]. 

The most popular way in acquiring mail addresses is still the use of so called harvesters, programmes 
spidering the web for mail addresses. Some studies prove this assumption ([1], [2], [3] and [4]). Harvesters 
or email spiders, as some are called, are easily available on the web: One of Germany’s biggest ISPs, 
T-Online, offered a quite big choice of them for download for their customersl. 

One way to stop harvesters collecting email addresses is to conceal them. In [5], [1], [3] some methods 
to hide mail addresses on web pages were suggested and a field test to prove their functionality was 
implemented [3]. 
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Tar pit 

Hiding addresses is one way to prevent harvesters from grabbing them. Another would be to set a snare 
for harvesters. A snare where they would be caught in and thus kept from crawling the web: A tar pit. 

Requirement s 

Setting up a functional and save tar pit is not as easy as it might seem at first glance: First, “honest” 
spiders, such as GoogleBot, should be kept out. Second: If the tar pit publishes links to itself, they need 
to be different. And last but not least the tar pit needs to make sure it is not hit by a denial of service 
condition if a harvester runs in circles through the site. 

Do not catch good spiders 

The first requirement, safeguarding the good, is easily implemented: Any decent spider should obey the 
robots, txt-standard [6], [7]. Excluding any spider from the page would do. If harvesters then learn not to 
ignore the robots.txt-standard, pages telling email addresses might then be hidden from them using the 
robots.txt-file. But as of now, harvesters do ignore robots.txt. From the harvester’s developers point of 
view this is a logical decision. 

I found this assumption to be correct when test driving real, downloaded harvesters against my test 
page. They all ignored the robots.txt. 

Generate different links pointing to the same file 

The next step was to generate new pages containing links to the page itself using different URLs. In my 
test setup, filenames might have between 5 and 30 characters each and there is a choice of different filename 
extensions like “.htm”, “.html”, “.shtml” or “.shtm”. 

Using symlinks on the server with every possible filename and extension would generate approximately 
4 * 36 32 « 2.5 * 10 5 ° links in the filesystem. Despite the huge amount of space needed only for the symlinks, 
most filesystems are unable to handle so many files in one directory in an efficient manner. 

Therefore, the web server should redirect any request received to the script. There are some ways to 
do so. One is mod-rewrite ([8], [9]), another uses aliases and the simplest is to use an Error Document. 
The later has the advantage to be available for almost anyone: Almost any of the webspace provider 
offering an opportunity to run PHP on their servers also allow the ErrorDocument directive within a 
“ .htaccess” -environment. 

The required ErrorDocument-directive is: ErrorDocument 404 /spamfight/index.php 
The only thing to take care of with this approach is to replace the 404-HTTP-Header with a 200-OK- 
HTTP-Header. But this is easily done: If a script sends a HTTP-Status, the web server will use this 
one. 

The alternative is using aliases. This usually requires access to the main web server configuration: 
<Directory /spamfight> 

AliasMatch "/spamfight/[A-Za-zO-9]+\.[A-Za-zO-9]+$ /spamfight/index.php 
</Directory> 

mod_rewrite offers amazing possibilities when mapping different URLs to a file. [9] even demonstrated 
how to implement a content-management-system based on mod_rewrite and some server side includes. But 
for the purpose of a tar pit, mod_rewrite has a serious disadvantage: It sends a “Location moved”-HTTP- 
Response. So a harvester might see it has been redirected to a location it has visited before. It might then 
recognise the tar pit. 

In my test setup I used the ErrorDocument approach, because it is easy to set up, totally transparent 
and more flexible then the aliases-approach: If I felt the need to include another file within the tar pit’s 
directory, the file would immediately be found. Using aliases, I’d either need to put the file in a different 
directory or modify my web server’s configuration. 

Avoid Denial of Service 

The most difficult task is to avoid a denial of service condition: If the tar pit publishes 20 links per page, 
the harvester will add those links to his list of pages to visit. On each of those links visited, it will receive 
yet another 20 links. Within a short time, the harvester has some millions of links in his list all pointing 
to the tar pit. In fact, the list grows exponentially. 
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If the harvester supports parallel spidering and is running on multiple machines, it might have enough 
bandwidth to pull the whole server down. If the server is only serving the tar pit, this does not matter - 
but if the tar pit is run on an otherwise used server, the “real” pages become undeliverable. 

To avoid those problems, the instances of the tar pit running should be limited to a maximum. But 
using PHP as programming language, there is no simple way to determine how many instances of the same 
script are currently running: ps -ef e.g. will not list those scripts. 

Implementing some kind of interprocess communication is needed. The easiest mean are semaphores. 
Binary semaphores are commonly used to programme mutually exclusive tasks: A semaphore S is created. 
Each task about to enter its critical section first does a P(S)-operation. This action is atomic, i.e. the 
operating system’s scheduler won’t interrupt it. P(S) decrements the semaphore by one if the semaphore 
is still greater than zero. If not, it will send the requiring process to waiting state and bring it back to the 
ready state as soon as the semaphore as it increased again [10). 

If the task leaves its critical section, it requires an V(S) operation. This - again atomic - operation 
increases the semaphore by one. 

Binary semaphores allow only one process at a time to enter a critical section. Looking at the way 
semaphores are implemented, one could easily use them to allow only a certain amount of processes in a 
critical section by using a start value greater than one. 

For the tar pit, the whole tar pit script is enclosed with P(S) and V(S). Doing so, the maximum 
of parallel processes is limited by the semaphore’s start value, e.g. if 20 processes are allowed to run 
simultaneously, the semaphore’s initial value is 20. 


Implementation details 

An example tar pit written in PHP is shown in the appendix. Besides the requirements listed above, there 
were some further details to be considered and first of all researched by analysing existing harvesters: Some 
harvesters for example will ignore pages offering more than a certain amount of links or email addresses, 
others have very aggressive time out settings to avoid being trapped by a tar pit. 

To circumvent time outs, the tar pit needs to deliver output slowly, but constantly, returning the 
impression of an up-and-running, but poorly connected server. 

To simulate links on different servers, a few domains have been registered and set up in the DNS in 
a way, that not otherwise explicitly listed sub domains would resolve to the same IP address. The server 
used IP-based and not name-based hosting. The tar pit in the appendix therefore changes the subdomain 
within links with a probability of 10% to a new random subdomain. 

Randomly changing the domain name is basically the same - but domain names should better be 
randomly chosen from a list of existent tar pit domains. 

To the harvester those links now look like they were from different servers, turning the tar pit more 
invisible to the harvester. 

With a view to have a more realistic looking but randomly generated link description, an alphabet has 
been included reflecting the language specific probability of characters and including some commonly used 
words. The alphabet could be extended to cover more real words. 

The length of a link description is also random to avoid patterns harvesters could match on. A further 
step in optimisation would be to randomly choose the amount of links listed on the page. Implementing 
this is trivial, however. 

The links themselves are also random-length fragments of a md5-hash over a random number. The file 
name extension is again randomly chosen from a list of possible extensions. Here again, an alphabet might 
be implemented to further obfuscate the tar pit. 

Also the page title and the heading might be randomly generated to increase the tar pits invisibility. 


Efficiency 

for efficiency testing, the tar pit has been installed on a virtual root server at one of Europe’s biggest 
providers. The server has been configured with security in mind: A manually compiled, minimal Apache 
and PHP were installed on a Linux box. Beside them, only a SSH server has been running, configured to 
offer maximum security. Unfortunately, due to the virtual servers architecture, there was no way to harden 
the kernel. 

The page soon got linked from a lot of anti-spammers’ web pages. Some of them even analysed the 
generated HTML and guessed own subdomains or created invisible links somewhere into the virtual file 
system. They so supported the concept of multiple host- and filenames. 
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The tar pit got a lot of visits - in the first few days mostly from humans or GoogleBot, who, after 
reading the robots.txt, did not get caught as it was intended. But less than one month after installation, 
the first harvesters left their traces in the tar pit. Some made up to 700 visits within two days. 

Only a few days later, another harvester made 14,000 page impressions in two days. A few months 
later, the top two harvesters spent more than 19,000 respectively 17,000 visits to the tar pit. 

Besides the optimisation hints given above, there are still some ways to further optimise the tar pit: 
Some harvesters list email addresses as they find them. Therefore, a tar pit should also generate valid 
email addresses, in the best case mail addresses leading to a SMTP tar pit. Then, a human overlooking 
the harvester would not even recognise the tar pit. 

The second step to optimise the tar pit is to spread it even more and have their administrators know 
each other. They then could easily exchange domain names and cross link their tar pits from each other 
thus obfuscating their existence even more. 


Other tar pits 

SMTP tar pits would be a nice add on to further increase the effect by further poisoning the addresses 
harvested. They could slightly reduce the spam delivery performance. 

But from the author’s point of view, SMTP tar pits alone are not an efficient mean to fight spam. 
Compared to SMTP-tarpits, as presented by [11], [12] and [13], the HTTP-tarpit has some advantages: 
First of all, it is preventive. A SMTP-tarpit relies on their mail-addresses harvested from the web and 
will then slow down the SMTP-connection in the hope to reduce the available TCP-connections on the 
spam-sending computer by closing up unprivileged ports. But SMTP allows to deliver more than one 
message per connection and there are approximately 64000 available high ports, i.e. a sender might open 
64000 parallel connections. So a spammer needs to connect to 64000 tar pits, to be cut of. To reduce the 
mail delivery performance by 50%, still 32000 machines are needed. 

The HTTP-tarpit by contrast uses one connection per request and as a long term effect poisons the 
harvester’s list of addresses to visit. This makes it a lot more effective. It might also educate harvesters to 
respect the robots.txt-standard, which in turn might be helpful in concealing mail addresses on web pages. 


Future research 

Future research is into combining HTTP tar pits with SMTP tar pits to increase the impact, and into 
better mechanisms to mask the tar pit. 

There will be further research into harvesters’ behaviour towards robots.txt: There are rumours, some 
harvesters would read them, but only to find additional links to follow - even if robots.txt states they are 
not to be visited by robots. 
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Appendix: Example tar pit source code 

<? 


/* ******************************************************************** 
Tar pit for harvesters 
Autor: Tobias Eggendorfer 
(c) 2004, 2005 

**************************************** ++++++ * +++4 . ++ ^ ++#++++++++##+ 

*/ 

/* Configuration 
*/ 


define("LINKS_GENERATED",5); /* Amount of links per page 

*/ 

define("TIME_WAIT",1); /* Time to wait between the output of two links 

*/ 


define("MAX_CONCURRENT_USERS",5) ; 

/* How many parallel instances of 
* the script are allowed? 

*/ 


define("SEM_PERMS",0660); /* Permissions for the semaphore, same as for files 

* within Unix’ file system. 

*/ 


define( MIN_WORD_LEN",5); /* Minimal length of a word generated from the 

* alphabet $alphabet 
*/ 

define("MAX_W0RD_LEN",30); /* Maximum length of a word 

*/ 


$extensions = array (’php’,>php3’,’php4’,’phtml’,>shtml’, 

’html’, ’ htm’,* xhtml’); 

/* Filename extension to use for 
* randomly generated links. 

*/ 


$alphabet = array (’a 1 ,’a’,’a',’a’, 
’b’,’b’,’b’, 
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999999 
) ) 


1 ) 

9 9 

) . ) 

* 9 

’der ’, 

’die ’, 

’das ’) ; 

/* Alphabet to generate link description over. 

* Repeating some characters increases their 

* usage probability having words look more 

* realistic. 

*/ 


/* Deliver HTTP-Header 

To be compatible to the suggested ErrorDocument-approach, 
HTTP-Status 200 is sent with every request. 

To avoid caching and / or proxies, the page is marked non-cacheable 
and always gives the current time for its last modification. 

*/ 

header("HTTP/1.1 200 QK"); 
header("Status: 200 OK"); 

header("Expires: ".gmdateC'D, d M Y H:i:s")." GMT"); 
header("Last-Modified: ".gmdateC'D, d M Y H:i:s")." GMT"); 
header("Cache-Control: no-store, no-cache, must-revalidate"); 
header("Cache-Control: post-check=0, pre-check=0", false); 
header("Pragma: no-cache"); 
header("Content-Encoding: iso-8859-1"); 

/* Output HTML-Header 

Note the additional warning for good spiders within the 
HTML meta tag. 

*/ 


?><!D0CTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 
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<html> 

<head> 

<title>Please follow all of those links...</title> 

<META name="ROBOTS" content="NOINDEX, N0F0LL0W"> 

</head> 

<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080" alink="#ff0000"> 
<Hl>Welcome to Spammer's Paradise.</Hl> 

<? 

/* Flush output buffer to send data to the harvester. 

*/ 

flushO ; 

/* Generate a key for the semaphore. 

*/ 

$sem_key = ftok (_FILE_ 

if ($semkey != -1) 

{ 

/* Got a key. 

*/ 

$sem_id = sem_get($sem_key,MAX_CONCURRENT_USERS,SEM_PERMS); 

if ($sem_id !== FALSE) 

{ 

/* Creation / Using semaphore succeeded. 

*/ 

if ( sem_acquire($sem_id) ) 

/* Critical section 
* P($sem_id) succeeded. 

*/ 

for ($i=0; $i<LINKS_GENERATED; $i++) 

$word = ’’; 

for ($j=0; $j<=rand(MIN_WORD_LEN,MAX_WORD_LEN); $j++) 

{ 

$word .= Salphabet [rand(0, coiint ($alphabet)-l)] ; 

> 

$basis = rand(0,15); 
print "<PXA HREF=\" " . 

substr(md5(uniqid(rand(), true)), 

$basis,$basis+rand(5,27-$basis)). 

II II 

lextensions[rand(0,count($extensions)-l)]. 

II ^ ll> II 

$word. 

"</Ax/P>\n" ; 

flushO; /* Again, flush output buffer. */ 
sleep(TIME.WAIT); 

> 


/* End of critical section 
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* V($sem_id) 

*/ 

if ( !sem_release($sem_id) ) 

4 

/* An error occured that should never occur: 

* V($sem_id) failed. 

* Better log it or send a mail to the webmaster. 
*/ 

die ('Internal Error’); 

} 

III end if sem_acquire 
} // end if sem_id !== FALSE 
} // end if semkey != -1 


/* HTML-Footer. 
*/ 


?> 


</B0DY> 

</HTML> 



Adventures In The Tar Pit - 
Implementing OpenBSD’s spamd 


David Purdue 
Sun Microsystems 

<david.purdue<3auug. org. au> 


Abstract 

spamd is the OpenBSD system for blocking spam from user mailboxes. It implements black listing based 
on Realtime Blackhole Lists (RBLs) and greylisting to determine if an incoming SMTP connection is spam 
or not. If a connection is deemed to be spam, spamd will stutter at the connecting machine in order to 
waste resources on that machine, preventing it from delivering spam to someone else, spamd determines if 
incoming email is spam or not based purely on the sending host’s IP address, not the content of the email. 

Implementation of spamd requires configuration of a number of OpenBSD systems, in particular the pf 
firewall software. 

This paper discusses some of the basic concepts of spam detection and prevention as implemented by 
spamd , and presents the configuration steps for the systems required to get spamd working. We conclude 
that spamd is a good implmentation of black and greylisting. 


Introduction 

spamd is OpenBSD’s spam prevention tool. It acts like an SMTP server, but will reject any email directed 
towards it, and in the process will try to slow down the machine connected to it. It integrates with 
OpenBSD’s pf firewall to ensure that the connections sent to it are from machines that send spam. 

This paper will go over the purpose of spamd and the concepts behind it. It will then cover the OpenBSD 
systems that need to be configured to implement spamd. It finishes by making some observations on spamd 
and drawing conclusions. 

This paper describes spamd as of OpenBSD 3.7. 


Purpose of spamd 

The primary purpose of spamd is to act as a tar pit; in other words to use up as much time and resource 
on the machine sending spam while using as little resource as possible on the spamd host. 

The main technique for tar pitting is stuttering - sending our side of the SMTP conversation to the 

spamming box v...e...r...y..s...l..o...w...l...y... - which by default is one character per second. The theory 

is that most spam is sent by zombies on virus infected PCs, and these zombies are single threaded and a 
poorly configrued email relay, so while you tie the zombie up in the conversation with you, it is not sending 
spam to anyone else. 

It is possible to keep a spamming box occupied this way for anything up to 10 minuites, sometimes 
more - although the zombies are getting smarter. Many will give up a connection of it takes more than 
a minute to deliver any one line. As a hack to get around this, spamd will now stutter on a line for 60 
seconds, then send the rest of the line in a rush. Even so, many spammers seem to give up after a minute. 

So - to reiterate, the purpose of spamd is to ensure that the mail you want gets delivered to your email 
system (Mail Transfer Agent, or MTA), while spam does not get through to your mailbox and the sender 
of spam wastes as much time as possible. How do we sort the spammer from the legitimate mailer? spamd 
discriminates solely on the basis of the source IP address of the incoming SMTP connection, and sorts the 
connection into one of three categories: Black List, Grey List or White List. 
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Black Listing 

spamd makes use of various real-time blackhole lists (RBLs), lists of IP addresses that are known to be 
sources of spam that are maintained by various organisations. Two examples of such lists - the ones used 
in our examples - are the Spamhaus SBL and Spews Level 1 RBL. You can also maintain your own black 
list of IP addresses that only send spam. 

It is important to remember that the only criteria spamd uses to sort incoming spam from incoming 
mail is the source IP address of the sending host. If a source IP address is on the black list, spamd will try 
to waste its time, and will not accept its mail.. 

Grey Listing 

Greylisting is an anti-spam technique that is now commonly implemented in many email systems. The 
main idea is that the PC zombies used to disseminate spam are simple beasts, and so if they do not 
succeed in sending a piece of email the first time then they will forget about it, where a legitimate email 
Mail Transfer Agent (MTA) will store the mail for later delivery. 

So to sort the spammers from the emailers, when ever a connection arrives from a particular IP address, 
and spamd does not know about the address (i.e. it is not on a black list and spamd has not seen it before), 
spamd tells the connecting mailer that the mailbox they want is temporarily unavailable. If they are a 
legitimate MTA, they will try again. 

The full course of a conversation with a legitimate MTA will run like this: 

• A connection is attempted, spamd records the source IP address, the envelope sender and the envelope 
recipient (i.e. the email addresses specified in the “MAIL FROM:” and “RCPT TO:” parts of the 
SMTP dialog). This data is known as the tuple, spamd also records the time of the conection. 

• spamd issues an error to the sender: “451 Temporary failure, please try again later.” Note that this 
is done before the “DATA” command is issued, so the body of the email is not transfered (if it is 
spam, we don’t want to see it). 

• An amount of time is allowed to pass - the “passtime”, which is by default 25 minutes, but is 
configurable. Attempts to deliver with the same tuple get the same 451 response in this time. 

• After the passtime, if a retry to the same tuple is seen, then the source IP address has its status 
changed from “GREY” to “WHITE” and deliveries from that are allowed to proceed to our real 
MTA. 

The assumption is that spam boxes, keeping themselves busy delivering millions of emails, either won’t 
try again, or won’t keep trying for 25 minutes. So the main argument against the effectiveness of greylisting 
is that spam robots are going to get smarter, and will start to behave like regular MTAs - storing failed 
mail for later delivery. 

The counter argument is that even if that happens greylisting will be somewhat effective. This is 
because greylisting introduces a delay in delivery of messages from unknown hosts, during which the host 
may be added to a black list. 

In addition, spamd has introduced the concept of “greytrapping”. Various email addresses that are 
known to only receive spam on your system are loaded into spamd' s database. If a system tries to deliver 
mail to one of the greytrap addresses, then that IP address will be blacklisted for 24 hours. 

The data in spamd’ s database will expire over time. If a mailer does not retry a tuple, it will expire after 
4 hours. Once they greylisting process has passed and the IP address is white listed, the white list data 
is kept for 36 days (to allow for monthly postings with greylist delays), spamd looks for more connections 
from systems in the white list, and if it sees incoming mail from those addresses or outgoing mail to those 
addresses it will reset the expiry time for another 36 days. The times are, of course, configurable. In 
addition, if an outbound connection to an unknown host is seen, it will be added to the white list so that 
replies do not suffer greylisting delays. 

White Listing 

It is important to maintain a white list as well - a list of systems whose mail will be delivered no matter 
what. There are several reasons for this: 

• You may want to be sure you get mail from certain sources, even if they accidentally get added to 
an RBL. 
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Figure 1: Overview of spamd operation 


• Some mail systems do not cope with greylisting very well, and you may want to get mail from them. 

For example, in some large email systems if the first attempt to deliver an email fails, the retry may 
be done by a different host in the same cluster. To spamd this looks like a different tuple, and so the 
email will never get past the greylisting process. Other mailers simply do not follow the standards - I have 
found examples in my logs of an email from a large Australian ISP that received the greylisting temporary 
failure, but was not retried and on investigation I found it was not bounced back to the sender. 

spamd has a white list mechanism, however in my opinion the syntax is poor and error prone, so this 
configuration will implement white lists by avoiding spamd. 


spamd Configuration 

spamd implementation involves a number of interrelated systems, as illustrated in figure 1. This paper will 
discuss the various components and the configuration needed for each one. 

pf configuration 

pf is the packet filter firewall built in to OpenBSD. It applies a set of rules to incoming or outgoing packets, 
and can be used to selectively pass or block traffic, to redirect traffic (send packets to a different host or 
port than their original destination), and even implement Network Address Translation (NAT). 

A full pf tutorial is beyond the scope of this paper - there is a lot of information on the OpenBSD web 
site. 

pf, acting as the traffic director, is the central component in spamd implementation. It is responsible 
for assessing each incoming connection and redirecting it to the MTA or to spamd as appropriate, as shown 
in figure 2. 

pf is configured via the /etc/pf.conf file. 

pf makes use of tables of addresses. The addresses in these tables can be manipulated via an ioctl 
(which is what the pfctl program does), so that the spamd black and white lists can be changed over time. 
Tables for spamd should be declared in pf.conf: 

table <spamd> persist 
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Figure 2: pf directs incoming connections 



Figure 3: Loading the white list into pf 


table <spamd-white> persist 

table <spamd-mywhite> persist file "/etc/mail/good_ips" 

The <spamd> table hold addresses that have been blacklisted by spamd. <spamd-white> holds the 
addresses of mail sources that have passed the greylisting process. The persist keyword instructs pf to 
keep the table even if no rules refer to it. 

A separate <spamd-mywhite> table is created since our configuration will handle white list addresses 
without using the spamd mechanism. The file keyword indicates that on pf initialisation the white list 
should be loaded from the / etc/mail/good-ips file, as illustrated in figure 3. 

If the whitelist changes then <spamd-mywhite> can be manipulated using pfctl (an exercise for the 
reader), or the table can be reloaded by telling pf to reload its configuration file: 

# pfctl -f /etc/pf.conf 

Macros can be declared within the pf config file using a simple “name = value” syntax, e.g. to declare 
a symbolic name for the external firewall interface: 

ext_if = fxpO 
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We will use macros for configuration values in this discussion. 

As stated above, pf is responsible for ensuring that incoming SMTP connections are directed to the 
correct daemon - either the MTA or spamd. 

Redirection rules are used to achieve this: 

rdr pass on $ext_if proto tcp from <spamd-mywhite> to port smtp \ 

-> $mta port smtp 

rdr pass on $ext_if proto tcp from <spamd> to port smtp \ 

-> 127.0.0.1 port spamd 

rdr pass on $ext_if proto tcp from !<spamd-white> to port smtp \ 

-> 127.0.0.1 port spamd 

rdr on $ext_if proto tcp from <spamd-white> to port smtp \ 

-> $mta port smtp 

The rules are processed in order, and after a redirection rule is processed any further rules are selected 
based on the rewritten packet, rather than the original. The pass keyword on a rule indicates that after 
rewriting the packet should be passed on to its destination without further processing (it is a shortcut). 
The first rule says that if the SMTP connection comes from an address on our white list, then pass it 
straight on to the MTA, no need to bother spamd. The second rule is for spammers - it sends connections 
that come from black listed addresses to spamd to get stuck in the tar pit. 

The third rule implements greylisting. For this rule to apply the connecting machine must not be on 
the black list nor either of the white lists. In this case it is an unknown IP, and so is redirected to spamd 
for greylist processing. 

Finally, this firewall will treat all incoming connections on port 25 as destined for the MTA, whether 
that was the original destination or not - you may or may not need/want this rule in your configuration. 
Note that the pass keyword on the other three rules tells pf to pass the packet as soon as it has been 
rewritten. Since there is no pass keyword on this rule, the rewritten rule will fall through to the filter rules 
below. This, as will be seen, is so that these connections (from spamd white listed IPs) can be logged. 

The rewritten packet will fall through to the filter rules: 

pass in log quick on $ext_if inet proto tcp from any to $mta \ 

port { smtp > flags S/SA synproxy state 

pass out log quick on $ext_if inet proto tcp from $oban to any \ 

port { smtp > flags S/SA modulate state 

The log keyword on each rule ensures that successful incoming and outgoing SMTP connections are 
logged to the pflog device. This information is used to refresh the <spamd-whitelist> entries, so that 
mailers that we communicate with regularly will not have greylist delays. 

spamd. conf 

/etc/'spamd. conf is where black lists and white lists for spamd are specified (except that we do not use 
the white list specification here). Its syntax is that of a capability database (as for printcap or termcap). 
There must be an entry for all, which specifies which black and white lists to use: 

all:\ 


:myblack:spamhaus:spews 1: 
Individual black lists are specified as follows: 
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spamhaus:\ 

:black:\ 

:msg="SPAM. Your address 7.A is in the Spamhaus Block List\n\ 

See http://www.spamhaus.org/sbl and\ 

http://www.abuse.net/sbl .phtml?IP=7«A for more details" :\ 

:method=http:\ 

:file=www.openbsd.org/spamd/SBL.cidr.gz: 

The first element is the name given to the blacklist, which is used in the all entry. 

Next, the keyword black indicates it is a blacklist - you’ll never guess, but “white” here would indicate 
a white list. 

The msg element is a message that will be returned to blacklisted SMTP senders, so that if the email 
was actually legitimate then the sender can see why it was trapped by spamd and do something about it. 
If the first character of this parameter is a slash (‘/’)> then the value is assumed to be the full path name of 
a file containing the message. A white list would have no message element (since the connection is passed 
to the MTA, so spamd does not provide a message). 

method indicates how the black list is to be obtained. This can be file , to read addresses from a local 
file (such as our bad-ips list), http or ftp to obtain the file from the net by http or ftp protocol respectively, 
or exec to obtain the list as the output of a program. 

The list must follow the syntax of having one address block on each line. Lines starting with a are 
ignored as comments. Each address block is either a single address, a range of addresses or a CIDR format 
address block. So some entries in bad-ips might be: 

# Fred has spammed me once too often! 

203.14.23.154 

# Don’t want mail from BigISP. 

123.12.0.0 - 123.27.255.255 

214.12.34.0/24 

And as a further example, this black list would be specified in spamd.conf as: 

# DavidP’s blacklist: 

myblack:\ 

:black:\ 

:msg="SPAM. 7,A has been blacklisted due to SPAM":\ 

:method=file:\ 

:file=/etc/mail/bad_ips: 

An example of a ”method=exec” list would be relaydb. This is a program that analyses emails to 
detmine which IP address sent it to you. Similarly to spamassassin, you feed it emails you like and emails 
you regard as spam, and it derives a database that separates IP addresses you like to receive email from 
and those you don’t. An example config is in the spamd.conf that ships with OpenBSD. 

A final note - if a white list is specified in spamd.conf, then it must be specified in the all entry after 
each black list that may contain addresses you want to white list. So the interpretation of this all entry: 

all:\ 


spamhaus:mywhite:spews: 
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Figure 4: spamd-setup loads black lists 


... would be to construct the blacklist by taking all the spamhaus list, remove the ones from my white 
list, add the spews list. So if an IP was in the spews list and my white list, it would be blacklisted. This 
semantic can be confusing, and so our configuration avoids it by using the spamd-mywhite pf table. 

spamd-setup 

The spamd-setup program reads spamd.conf to determine the sources of black list addresses, it then 
compiles the consolidated black list and loads it into the <spamd> table in pf, as well as loading the 
list and messages into spamd so that it knows what message to send as part of the SMTP conversation 
from black listed hosts, as shown in figure 4. 

spamd-setup is invoked by cron, usually every hour or half hour. An entry has to be made in root’s 
crontab: 


# SPAMD blacklist maintenance 

*/30 * * * * /usr/libexec/spamd-setup 

Greylist Processing 

All state information is held in the file /var/db/spamd. The contents of this file can be viewed and 
manipulated using the spamdb program, /var/db/spamd can contain four types of entries: 

A SPAMTRAP entry holds an address in your domain that only ever receives spam: 

SPAMTRAPImailaddress 

If a host tries to send email to this address, it will be black listed for a period (by default, 24 hours). 
A host that has fallen into the trap will have a TRAPPED entry: 

TRAPPED I ip I expire 

The IP address of the offending machine and the expiry time for the black listing (in seconds since the 
epoch) are recorded. 

The remaining two types of entries hold state infomation for machines going through greylisting and 
addresses of machines that have successfully passed and are now white listed. These two types of entry 
have the same format: 

GREY I source ip I from I to|first I pass I expire|block|pass 

WHITElsource ip| | I first I pass I expire I blockIpass 

The IP address of the host in question is recorded, along with (for GREY entries only) the envelope 
from and envelope to address for the email that triggered the greylist process (the tuple), first is the time 
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db/spamd 


spamdb 


Figure 5: /var/db/spamd holds grey list state 



Figure 6: spamlogd updates /var/db/spamd 


that the first email from that IP address was seen, pass is (for WHITE entries) when the address moved 
from grey to white, and expire is when the entry is due to be purged from the file. Finally, spamd records 
how many times the tuple was blocked while going through greylisting, and for white list entries how many 
mails have successfully been delivered from that address. This last piece of information is gathered by 
spamlogd, as described below. 

As mentioned, the spamdb command can be used to examine the contents of /var/db/spamd. It can also 
be used to add or delete arbitrary entries from the database. In particular, this is how you add greytrap 
addresses: 

# spamdb -T -a spam_me@example.com 

spamd scans /var/db/spamd to generate the <spamd-white> pf table and add trapped addresses to 
the <spamd> table, spamd also updates entries in the database to keep track of its state during greylist 
processing. This is illustrated in figure 6. 


spamlogd 

pf should be configured to log successful inbound and outbound SMTP connections. This data is used by 
spamlogd to add or update the expiry time on WHITE entries in /var/db/spamd, as shown in figure 6. 

pf logs activity to the pflog pseudo-device, spamlogd picks the connections up from there and uses the 
information to update /var/db/spamd. This is to ensure that people we send mail to are automatically 
white listed, so their reply will arrive quickly, and people who reguilarly send us mail will remain white 
listed, avoiding greylist delays. 

Logging spamd Activity 

If you want to see what spamd is up to, you can log its activity via the standard syslog mechanism, as 
shown in figure 7. 

In this configuration we use verbose logging, which requires invoking spamd with the -v flag. This entry 
in /etc/syslog.conf will cause spamd' s activity to log to /var/log/spamd: 

# SPAMD loging 


!spamd 
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daemon.err;daemon.warn;daemon.inf o;daemon.debug /var/log/spamd 

To keep the log file manageable, it is advised that log file rotation be set up for this file. Add the 
following entry to /etc/newsyslog.conf: 

/var/log/spamd 600 7 * 24 Z 

This says that that the spamd log files should be created with permissions 600, the last 7 versions of 
the log should be kept, size does not matter (when working out when to rotate this log file), rotate every 
24 hours, and compress the old log files. 

One nice thing about keeping log files is that it allows you to see how much time you are wasting on 
spammers’ machines, e.g.: 

Aug 19 17:30:12 scapa spamd[28579]: 200.78.121.253: 
disconnected after 1491 seconds, lists: spewsl 

Invocation 

At boot time the spamd daemon needs to be started. This is done by the /etc/rc script, which also does 
an initial run of spamd-setup to ensure an up-to-date black list is loaded. If greylisting is enabled then 
spamlogd is started at the same time. 

This only happens if spamd has been configured to start by editing the spamd variables in /etc/rc. conf 
although best practice these days is to redefine these variables in rc. conf.local: 

spamd_flags="-v" # for normal use: "" and see spamd-setup(8) 

spamd_grey=YES # use spamd greylisting if YES 

spamlogd_flags="-i fxpO" # use eg. "-i interface" and see spamlogd(8) 

As mentioned above, we invoke spamd with -v for verbose logging, and we also enable greylisting. 


Observations 

spamd And Spam Prevention 

Black listing is not an idea that sits well with the author intellectually. It seems a shame that the way to 
make the Internet usable is to cut off great chunks of it - for example, some people use spamd to block all 
email from Korea and China, since a lot of spam originates from there. Some go so far as to only accept 
mail that originated in the USA. Fortunately these are not the sort of people I want to send email to 
anyway. 

Greylisting and greytrapping have much more appeal. Greylisting simply forces people who send me 
email to obay the store and forward provisions of the RFCs. Greytrapping will definitely catch senders of 
spam, but may stop some legitimate email from being delivered. In practice greylisting has significantly 
reduced (but not eliminated) the number of spam messages I receive. 

It should be noted that spamd can be used without greylisting (just don’t turn it on) or without 
blacklisting (just define a single empty blacklist) if you only want to use one of these features. 

spamd And RBLs 

Most RBLs allow a real time lookup of whether an IP address in in their blackhole list via DNS. Unfor¬ 
tunately spamd does not use this mechanism - a list of IP addresses must be provided. The trouble with 
this approach is that there can be a significant delay between a host being listed in an RBL and that host 
being added to the spamd pf table. 
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Infrastructure Requirements 

To set up spamd you will need an OpenBSD machine. (Actually, spamd and pf have been ported to 
FreeBSD, but configuring spamd on FreeBSD is somewhat different to what is described here.) 

However note that you are not required to run your mail server on this OpenBSD machine. The 
configuration shown here in fact will forward white listed SMTP connections to another machine (designated 
by the $mta pf macro). 

And although spamd is tightly integrated with the pf firewall software, it is not necessary to make the 
OpenBSD box your firewall - it does not even have to have multiple network interfaces. If you do not want 
to replace your firewall with pf, then you can sit the OpenBSD box on your network. As long as the MX 
record you publish in DNS points to the OpenBSD box, incoming connections will be handled by spamd. 

New Tricks 

Some spam delivery systems are getting wise to tar pits, so when they see a stuttered connection they drop 
the connection straight away. Legitimate email systems will ignore stuttering and just carry on with the 
SMTP conversation as best they can. 

This information is used to improve greylisting in the upcoming OpenBSD 3.8. If an unknown system 
connects, it will go into greylisting as above, but the first 10 seconds of the conversation will be stuttered. 
If the sender is a tax pit aware spammer, it will disconnect. On the downside you are not wasting their 
resources. On the plus side, you yourself aren’t receiving that piece of spam. 


Conclusions 

In an ideal world there would be no spam. In the real world there is ever increasing amounts of it, and 
while it is not ideal, blacklisting and greylisting are good techniques to stop a lot of it from being delivered 
to your mail system. 

OpenBSD’s spamd is a good implementation of black and greylisting, and at the time of writing seems to 
be the only implementation of greytrapping. Its use has been shown to significantly reduce spam, however 
there have been a few “false positives” caused by misconfigured mail servers trying to deliver legitimate 
email. 

Implementing spamd requires configuration to a number of OpenBSD systems, so is not as straightfor¬ 
ward or user friendly as it could be. However, the knowledge that you are wasting spammers’ time and 
resources scores well in the warm fuzzies department. 


References 

• OpenBSD: http: //www. openbsd. org/ 

• Greylisting: http://www.greylisting.org/ 

• Spamhaus: http: //www. spamhaus . org/ 

• Spews: http://www.spews.org/ 



It’s nearly cheaper to build a smart 
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You might have heard a saying that “if we built houses the way we build our computer systems, the 
first woodpecker that came along would destroy civilisation”. Don’t believe it. In some ways, the software 
industry has caught up - we expect far more reliability from a typical piece of commercial software than 
we expect from our buildings. 

Does that surprise you? Have you ever measured down-time for a typical residential property? How 
long do we tolerate a broken burglar alarm, or air-conditioners, or the odd faulty fuse? 

We’re inconsistent in the way we apply our standards. And that leads to very different expectations 
about what building management systems should and shouldn’t do. 

The Chinese have a phrase “a chicken versus duck talk”. The chicken and the duck are probably both 
talking about something similar - ’’let’s eat that worm” or “love the new feathers you’re wearing” - but 
one quacks and the other clucks and they don’t really understand each other. 

You end up with chicken-and-duck conversations whenever you try to merge two very different industries. 
And embedded software systems development and the building industry are very, very different universes. 

I’ve had a lot of chicken-and-duck conversations over the last three years, and I’m going to share a few 
of them with you today. 

I should perhaps add at this point that I’m only talking about smart housing on new, large residential 
complexes. These are places where it makes sense to have servers in the basement serving hundreds of 
light-weight touchscreens in each apartment. 

Retro-fitting existing buildings is a different story, with different economics. Standalone houses are 
a different story again. Retrofits and standalone houses are so expensive that I don’t forsee any great 
revolutions happening there for a long time yet. 

But as I’ve alluded to in the title of the talk, we’re almost at the cross-over point where an intelligent 
building is as cheap to make as a dumb one. 

I became involved in what was going to be an “intelligent apartment intranet” in early 2002. “Intelligent 
apartments” back then meant that when you bought the apartment, you also got a PC included in it, and 
that there was a Webserver somewhere (maybe not even in the building) which would host a couple of pages 
for booking facilities (such as tennis courts), and maybe run a mail server as well. 

An Australian property developer had approached a couple of IT service companies in the area and 
received absurdly high quotes for putting together such a system. One of the developer’s new staff had 
used my company’s services in his previous job, and in the end, we won the job. 

In what must win some kind of award for scope creep, we ended up something like 50 times over the 
original budget. This might have been our first chicken-and-duck. 

A lot of subsystems were added. Originally the plan was to use commercial off-the-shelf control systems 
for burglar alarms and environment controls (e.g. airconditioners). But they are expensive to buy, and 
generally can only be set up using very limited proprietary programming languages which hardly anyone 
knows. 

Then came access control - it would be nice to have the same PIN to enter the building as you use 
to unlock your security system. Then billing - wouldn’t it be nice to have one bill for water, electricity, 
internet usage, body corporate fees and so on. 

And if there’s ethernet cable throughout the building anyway, then you might as well use it for accessing 
security cameras. And you could have a common music library for all residents, and audio-over-IP sound 
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systems to play it on. You could run your intercom systems over it as well, and send the “door buzz” 
commands back to the front door over IP as well. 

It grows like topsy. It’s 100Mb ethernet (or faster), so people start thinking “you can deliver audio over 
IP, let’s deliver TV over it as well.” 

It gets rather compelling after a while. Instead of running a multitude of different proprietary cabling 
systems through a building, you could just about get away with just power and ethernet. I doubt that 
we’ll ever get to the point that we can have just one - AC power circuitry offers terrible bandwidth, and 
you can’t, power much from a couple of lines of power-over-ethernet. 

Actually, we’re not quite there on “just power and ethernet”. There are still bits of RJ12 cabling here 
and there - the range is better, and also no sales person wants to go through with the pain of explaining 
“no, you don’t need to get a phone service, we already have a voice-over-IP PABX in the basement, and 
you can just use that”, so you end up having to run cabling for direct connection to the PSTN. You can 
hear the echo of another chicken-and-duck conversation there too, can’t you? 

What surprised me was the most expensive and annoying wiring that property developers hate is 
actually pay TV. If the whole building isn’t completely wired up for it, you lose sales, but after footing the 
bill for doing it, you’ll be lucky if you even get a handful of people subscribe to it. 

So if anyone wants a suggestion for a profitable thing to build, come up with a small box that has 
an ethernet connection on one side which takes an MPEG stream or some such, and has a standard TV 
connector on the other. Make it small enough that it fits into a wall cavity. That would eliminate another 
set of expensive wiring that needs to be done. 

The electrical work in a typical new residential apartment can involve upwards of two person weeks of 
an electrician’s time. In countries where labour is expensive, that’s a significant cost. 

So the challenge is, can we save enough money on the labour and physical material cost to justify the 
extra smart infrastructure you need to do everything over IP? 

The answer is: nearly. It depends on how many corners you want to cut and how many compromises 
you want to make. And this is where most technology geeks (including me), get it hopelessly, hopelessly 
wrong. 

If you hadn’t guessed, this is going to be another chicken-and-duck conversation. 

For most of the project I had at the back of my mind that we were developing something that would fit 
in to a spaceship from Star Trek. Or a smart, autonomous system that would run quietly in the background 
and “just work”. I find it annoying when my internet connection at home is off-line for half an hour (I 
work from home, but even out of hours). So my expectations were that I would be even more annoyed if 
my burglar alarm wasn’t working when I wanted it to, or that the proximity card in my car failed to open 
the boom gate as I drove up. Learned helplessness and all that. 

I don’t mind paying an extra premium for my next house if I know that the wiring and systems are triply 
redundant, with its configuration duplicated off-site in case of a disaster, and able to recover smoothly in 
some sort of diminished capacity from being hit anywhere by a runaway truck. And ethernet ports directly 
connected to a high-speed network in every room - fabulous! Sign me up! 

Unfortunately, technology geeks are a very small market. We don’t represent what a typical consumer 
wants. 

Actually, in my less humble moments, I suspect that I’m right and the rest of the world is wrong. We 
shouldn’t tolerate systems that break down because there’s no built-in redundancy. Why wasn’t it designed 
properly in the first place? 

Anyway; most of the residential property market don’t give a hoot. If there are two apartments 
advertising similar experiences and one is $1000 cheaper that the other, then the expensive one gets stuck 
on the market unable to sell. 

I found myself trying to balance conflicting constraints. On the one hand: 

• Our budget for hardware, third-party software and installation time was dictated by getting under 
the cost of paying an electrician to wire up a more traditional system. That is, perhaps a couple of 
hours of tradesmen’s wages. 

• The long-term maintenance cost has to be low, because there axe very strict rules about what’s 
reasonable in body corporate fees. 

So it has to be cheap, very cheap. On the other hand: 

• The building management system had to be still usable in 10 years’ time. Most buildings will still 
be standing long after that. Retrofitting is hard and expensive, and needs to happen as rarely as 
possible. 
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• Somehow it has to be very resistant to failure - partly to keep the maintenance cost down, but also 
for customer satisfaction. 

Originally I had set myself the goal of looking at keeping the level of downtime down to a few minutes 
over the lifespan of the project. So early versions of the software were written in Erlang (a very funky 
programming language developed by Ericssons, that lets you update the software without shutting down). 

By this stage we’d progressed beyond putting a full PC in each apartment, and it had become a diskless 
touchscreen embedded in a wall. It was pointed out to me that the touchscreen displays don’t have to be 
all that highly available - it’s OK for them to shutdown at 2:00am in the morning every now and then for 
a software update. 

Also at this stage, the idea of having a proactive monitoring system had come about. With just about 
everything being IP-based, a VPN from an off-site response centre to the apartment building combined with 
some statistical smarts and you start getting calls from an operator saying, “Hello, you’re the registered 
building manager. We thought you might want to know that your front door isn’t unlocking and opening 
correctly; do you want us to send a locksmith out to look at it?” 

But still I was trying to figure out how failure-tolerant the system had to be. It’s not easy to do. 
Obviously, you don’t have to be as hardened as a military system, where the cost of a problem is probably 
going to be someone’s life. It’s not a clear money-versus-money calculation as you get in a commercial 
system where the cost of the system being off-line for an hour is measured in dollars, and the cost to make 
sure it isn’t off-line for that hour is also measured in dollars, and you can just multiply out the probability 
of each of the different failure modes and figure out whether you need to add another backup component 
or not. 

For me, in my Star Trek universe, I think I’d want the technology in my apartment to be perhaps 
around the same level of reliability as an insurance company, or maybe a retailer. 

But this isn’t what the market seems to want, which is a pity. 

At one stage I tried to nail down with the property developers exactly what level of down-time and 
outages were acceptable. The response I got to this was quite surprising to me - another chicken-and-duck 
conversation - they thought I was wasting everyone’s time asking the question. 

People who buy property don’t think about down-time and outages. 

The only real requirement is for the system to be better than everything else on the market. Now, as 
an exercise, try searching google for building management systems with any kind of failover capability at 
all. Or ask the next salesperson trying to sell you a smart house about their redundant backups. 

So it wasn’t hard to be substantially better than everything else on the market. We have some basic 
failover capabilities (a shared SCSI storage array for the root disks of our servers), load-balanced firewalls 
and a spaghetti tangle of crossovers for our core switches. 

In my dreams, I’d love to have our video surveillance storage servers have a backup or failover, but if 
we did that, property developers wouldn’t buy that component. The watchword even at the premium end 
of the market is to push supplier costs down - and traditionally, video surveillance storage consists of a 
bunch of analogue video cassette recorders getting feeds from closed circuit televisions. Yes, the heads on 
the video cassette recorders wear out after a year, and yes, it’s very silly to have someone having to come 
and replace the tapes every couple of hours, but any smarter solution has to match that price point, or at 
least get near it. How many VCRs do you need to replace to pay for a server with enough disk storage 
space to record the same amount of data, and keep it for longer? 

Interestingly, there’s a phenomenon of human behaviour that makes you not want to push the failure 
rate down too low. Here’s a quick question - which is better, 

(a) a system that has one failure every five years which takes half a day to fix, or 

(b) a system that has one failure every five years which takes half a day to fix AND has a failure every 

six months that takes five minutes to fix? 

Obviously (a) is better in some sense, but after 4 years of never having a problem, would your body 
corporate be willing to pay for a fifth year of a support contract which you are not using? In scenario (b), 
of course you will continue on your long-term support contract, because you can see clearly how useful the 
support contract is. 

How happy are you with your service contract? In scenario (a) the average time-to-fix for each problem 
is 4 hours. In scenario (b), the average time-to-fix is a bit over 20 minutes, and it would seem that you are 
vastly more efficient than the team providing a service such as (a). 

I’d like to say, “so therefore we put in some random bugs that manifest themselves every six months 
and disappear spontaneously five minutes after a technician logs in.” But we didn’t. We’ll leave that trick 
for some other vendor to pull. 
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Security has been interesting. Some of our initial network designs were awful and it took a long time 
to come up with the level of segmentation that we deploy now. For example, in Australia, there are 
strict privacy regulations about who can access stored video footage, so we’ve kept the surveillance storage 
servers off on an isolated firewalled network to ensure no access. Interestingly, I haven’t found a single 
other vendor doing anything like that, which to my mind means that no-one else’s product is legal. 

You might have been aware of a growing sense of unease in a lot of industries about the security of 
their SCADA systems. Over the last few years many companies have abandoned proprietary supervision, 
control and data acquisition networks, and started putting in TCP/IP-based embedded devices. Usually 
this consists of wrapping an existing serial-based control structure in a board that offers some kind of 
TCP/IP connectivity. 

The security of these networks are, in general, breathtakingly awful. The last time I did a security 
audit of a SCADA network (last year), it ended up turning into a national security issue. Nope, I’m not 
kidding. That’s for large well-built mission-critical systems and money is not tight. 

I shudder to think of what most smart housing systems of the future are going to be like if the same 
kind of slipshod work is done there. Will we see hackers breaking in and turning on and off burglar alarms 
and fire sprinklers? Probably. 

What did we do for our SCADA network? We couldn’t do much about our I/O boards. Price constraints 
dictate assembling the cheapest thing we could make. After all, there will be a lot of sensors in a decent¬ 
sized building when you start to make fly-by-wire every lift call button, emergency door notifier, and so 
on. 

But we can do a lot with the network infrastructure. Our I/O boards are firewalled gruesomely off from 
the network. They are isolated in the network from each other. The only servers that connect to them run 
OpenBSD. And so on. 

We know that we’ll be supporting some old versions of OpenBSD, and back-porting patches to it from 
now until sometime in the middle of next decade, but that’s a price we’ll pay. We could perhaps have used 
Linux or one of the other BSDs, and there are many things that would have been easier to implement if we 
had, but security has to be the top priority. When you are building a system that is going to be used at 
home by lawyers who have become rich enough to afford premium residential apartments, you tread very 
carefully indeed. 

Surprisingly, by far the hardest part of this work has been the user interface. To have a long life, there 
need to be almost no moving parts in the touchscreen in each apartment, so that rules out hard disks. If we 
want highly interactive and fast response the processing power needs to be on the touchscreen controlling 
hardware, not on some distant central server - particularly as it may be serving hundreds of apartments 
simultaneously. 

We have to use the cheapest possible commodity hardware. It’s not pleasant, and it conflicts with 
the goals of providing a long life, but the market simply won’t pay the extra money to buy top-quality 
thinclient hardware - and when a typical installation will need hundreds (or at least several dozen) clients, 
the property developer can’t wear the price difference and still make a profit. 

This was difficult, because the quality of software and driver support in the open source platforms gets 
distinctly worse the further down-market you go. OpenBSD support? Forget, it. Linux? Only just. 

So we found ourselves trying to find a Linux distribution which was: 

• up-to-date enough to have every last obscure driver BUT stable enough that we could work with it 
and deploy products with a long life span 

• complete in all the packages we would want to have (voice-over-IP software, web browsers, media 
players, development environments) BUT small enough that it could be booted over the network 

• designed for network booting and thin-client operation BUT able to continue working during network 
interruptions, and to use local processing power. 

You might have noticed three pairs of utterly and completely conflicting goals there. 

Needless to say, we couldn’t find anything that did what we needed. The closest (and it was a long way 
off), was Miles Roper’s Thinstation distribution. 

So we funded some development, to get the bits we needed. The end result is kind of interesting. It 
now has a very complete Tclkit environment, so we can build, deploy and update applications written in 
Tcl/Tk very simply. We ended up writing our entire configuration management definitions in Tel (more 
about that later), and so we needed Tel programs everywhere. 

Having voice-over-IP client software on a thin client distribution will probably become standard over 
the next few years as larger companies continue their migration away from traditional phone services. We 
needed it sooner than that, and funded Miles to include at least SIP support (with IAX and H323 being 
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on the cards as well) in this release. We chose just to use command-line clients so that we could wrap our 
own interfaces around it. 

Very few of the thin client Linux distributions include out-of-the-box support for touchscreens, which 
is surprising, so we’ve had to take steps to remedy that. 

And finally, we wanted to build on OpenBSD, so we managed to get enough of a cross-build environment 
that we can build the Thinstation Linux distribution under OpenBSD. 

I think Thinstation is going to be worth watching over the next few years. It is beginning to get some 
useful functionality that takes it beyond being “just another thinclient solution for replacing desktops” and 
becoming “here are some remarkable new ways of working”. 

But enough of business; back to residential smart housing. 

Most larger networks evolve over time. It is rare to find a company put on 100 staff in the space of two 
weeks and for them to expect to walk in all on the same day and have a complete working system ready 
for them. But that is the deployment timeframes that we have to work in with a new building, and the 
networks that need to be deployed are complicated - and even one wrong cable plugged into the wrong 
port on a switch would be enough to make a customer irate. 

One of Joel Spolsky’s golden rules of software development (he has 12) is to make sure your system can 
build from scratch in one step. We’ve taken that to heart. Each new site gets a complete site definition 
down to excruciating detail. Every port on every switch is enumerated, detailing what VLAN it belongs 
to, and which interface on which computer the cable goes to. Every wire attached to every I/O board is 
marked for its name, and its role, and all the finite state machines that it plays a part in. 

From that our software assigns IP addresses and subnets for every interface on every computer, a 
complete set of firewall rules for both firewalls, DNS zone tables, DHCP configuration, access control 
rules for the database, apache configuration, asterisk client and voicemail configurations, the phonebook, 
the phone directory, tftp boot areas for network booting the touchscreens, timezone specifications for all 
operating systems we use, network time synchronisiation configuration files, database schema creation and 
population, racking diagrams, state machine interpreter definitions, the screens for the user interface, and 
a few more things that I’ve probably forgotten. 

Then, the build system can run an installer program which talks through to our server’s RS232 serial 
consoles to automate every step of the OpenBSD install sequence, reading the questions that OpenBSD 
asks, and answering them with the appropriate answers based on our configuration files. 

We haven’t quite been able to remove any human interaction from the setup process. The cameras 
we’re using don’t default to DHCP, so they need to be modified manually, and we’re still trying to get core 
switches at a decent price that can be reconfigured from scratch with a sensible API (even a Cisco IOS 
command line would be good enough, if only we could get a managed switch from them cheaply enough). 
Of course, while we can create wiring diagrams, we don’t have a robot yet that can actually plug the cables 
in. 

Testing a big network like this is hard. Not least because the cost of having enough hardware around to 
do a full test of a large apartment building is prohibitive. Also, the huge number of interactions between 
components starts getting mind-boggling. 

We’re not yet at the stage that we have automated testing and coverage suites. I’d like to get there, 
but that’s going to be a very complicated job. We have software emulators for our I/O boards, and by 
playing games with OpenBSD’s bridging capabilities, we’ve managed to come up with ways of emulating 
dozens of VLANs at a time on VMware Workstation, but we’re still stuck on emulating IP cameras and 
IP-based music players. Any suggestions welcome! 

Even then, while we can emulate and test the functionality of our software, testing the whole system 
is difficult again. We have some code that checks to see if the number of ticks co min g in from a water or 
electricity meter is reasonable (within a few standard deviations of what it normally does). But how do 
you test that? Get a bunch of testers to stand in the shower for longer than normal, or burn a couple of 
extra slices of toast? 

Some things are deceptive - they seem easy to test, but actually aren’t. The target market are not 
comfortable with computers, and usability testing for the inexperienced is very important. 

It’s easy enough to test for user-interface usability now. Organise a team of aged grandmothers (or 
other people likely to buy apartments the system gets deployed into) and see what happens to them. But 
what of the person that buys an apartment in (say) 2015, just before the system is due for replacement? 
What are the metaphors they will be expecting when they interact with a computer? As a sample - take 
someone who’s first computer was running WinXP from 2001 and put them in front of a really nicely 
designed MS-DOS application from 1991. Will they understand it? Will they be able to use it? 

We don t have a solution to this — how do you predict what a ’’typical” application userinterface will 
be in 2015? You can’t, and yet somehow we need to come up with something that makes as much sense to 
a user accustomed to the current generation of technology as to the hypothetical user next decade. 
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IT’S NEARLY CHEAPER TO BUILD A SMART APARTMENT THAN A DUMB ONE... 


Dumb apartments are much easier to build. You don’t have to think about security, testing, reliability, 
saving on money or long term maintenance. At the moment smart housing is still a premium thing for the 
rather rich or extremely geeky, but that will change. As labour costs go up, and component costs go down, 
we’ll probably pass the point soon enough when every new apartment building is wired for full integration 
because it’s cheaper than treating every subsystem separately. 



Gone Phishing... 


Paul McGowan 

Yawarra Information Appliances 
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Epimetheus - some ideas for reducing the risks associated with 
phishing attacks. 

So, what’s this all about? It seems to me that many phishing attacks can be prevented from doing any 
damage, with some fairly straightforward measures. 

Epimetheus was the greek titan, whose name means hindsight, or afterthought. Too many banks fall 
into the trap of trying to prevent fraudulent access rather than simply mitigating its risk. It’s very easy 
to see what the right thing to do was in hindsight, so lets use it. Intrigued? read on... 


What this document is 

This is a set of ideas, intended to provoke thought in the right direction. It should be used to get you 
into the frame of mind that will allow you to see what it is about fraudulent transactions that makes them 
different, and hence detectable. Every system is unique, though they all have some common characteristics. 
The way to get the answer you need for your particular system is to learn how to ask the right questions. 
Hopefully, the techniques discussed here can assist in that direction. 


What this document is not 

This is not intended as a simple how-to document, ie. Follows steps 1-10 and all your phishing worries 
are over. Sorry, it doesn’t work that way. The bad guys are in this for money, and they are thinking very 
hard about ways to get it. Until you are willing to invest at least at much thought into ways of preventing 
them, they will continue to successfully steal from you (or more precisely, from your customers, through 
you). 

Basic requirements 

Stop the bad guys” from stealing money, without making it harder for customers to use the system. 


One possible solution 

So, say your bank uses a username and password to login to your account. Conventional wisdom (?) says 
that you need to prevent the bad guys from stealing your username and password, right? WRONG! What 
you are trying to prevent is the bad guys stealing your money. This distinction is very important. If 
you have an account with $0 dollars in it, which you never use, what does it matter if someone knows the 
access details? Your username and password are only valuable insofar as the bank allows anyone who knows 
them to take your money. And therein lies the REAL problem. The bad guys will get valid usernames 
and passwords somehow (and you won’t know when they do). You cannot prevent this happening, so stop 
wasting your energy trying. Concentrate on fighting the battle where you have complete control - inside 
your own system. Do what world renowned security expert Bruce Schneier describes as “authenticate the 
transaction, not the person”. While it is incredibly difficult to prevent the bad guys from stealing access 
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credentials (especially with browsers like Internet Explorer around), it is actually much simpler to prevent 
your money disappearing off to some foreign country. 

It’s all about choosing the battleground, and shifting the balance away from the protection only hap¬ 
pening at the user’s PC. The user’s PC is possibly the worst place of all to try to secure the banking 
system, as the bank has no say whatsoever about what software is installed, who uses it, what other things 
are done with the machine and so on. It’s a lost cause. I will say now that there is no way you can prevent 
access credentials being stolen. There are as many points of failure as you have customers. So, some banks 
are adopting what is known as 2 factor authentication, but this isn’t really much better. It still leaves 
100% of the security for the system in the hands of the users. This is wrong in so many ways. 

When something goes wrong, the bank will tell you that you “authorised” the transaction, where in 
fact the party who ultimately “authorised” it is the bank, based on the information they chose to take as 
evidence that this transaction is the genuine desire of a legitimate customer. The problem is, right now 
the only information they are basing this decision on is a username and password. What they apparently 
don’t realise is that they have access to a huge amount of other information that can help to determine 
whether this is really what the customer wants. Some of this information is immediately available with 
each transaction, and some can be readily inferred from historical context. The bank has access to all of 
it, and the more you use the system, the harder it should be for a thief to take your money. 

Consider the following: There exist today (and have for several years) publicly available databases 
(albeit for a modest fee) of IP address blocks matched to country and even city. That is, for not very 
much effort at all, it is possible to determine the location (to the nearest major city) of anyone accessing 
the bank, via their IP address. Now consider most internet banking customers. Where do they do their 
online banking? Two places. At home, and at work. Further, in most cases, these two places are in the 
same geographic region. So, when I access my account, it is done (pretty much without exception) from 
Melbourne, Australia. Now, consider where the phishing fraud comes from. I am led to believe that for the 
most part it comes from places other than Melbourne, Australia. Why then, I ask you, should my bank 
(which knows where I live) accept, without question, a request for a transfer of funds out of my account 
from anywhere else, especially somewhere not in Australia. “Oh, but you might be travelling”, I hear you 
say. Yes, I might be, but then again, I am probably not travelling in Eastern Europe, and wanting to 
transfer several thousand dollars to an account in the Cayman islands am I? How likely is that to be a 
legitimate request? Yes, it is possible, but not probable. So we file that likelihood away and go on to the 
next piece of unused information. 

Most people who use internet banking do it during their waking hours. And most people are awake 
during the day and alseep at night, that’s why the roads are so quiet then, and so horrible in peak hour. So, 
it is more likely that I will be doing my internet banking during the normal waking hours for Australians. 
That is, between about 8am and 10pm. Moreover, if I am doing it at work, it is more likely to be during a 
break of some sort, lest the boss get shirty with me for wasting company time. However, what is probably 
more important than me trying to speculate about when you will do your banking, is the fact that the 
bank should know when they are usually busy, and when they are not. They have all the data they need 
to say “Gosh, 4am is certainly an odd time of day to be doing your banking Mr McGowan. Oh, and look, 
you seem to be in Nigeria, that must be interesting for you... Yes, no problem we’ll send your funds to that 
account in Nigeria immediately, as you’ve proven to us by entering your password that you really want us 
to.” And on we go to the next exciting piece of the puzzle. 

Most people don’t have access to a large and ever changing group of computers. They have access to 
one or two. Typically, one at home, and one at (you guessed it) work. By and large these are the same 
PC’s every day. Many years ago, a technology known as cookies was introduced to the world by Netscape 
Communications (bless them). Using this simple, ubiquitous technology, it is trivial to place an identifying 
mark on a computer for the purpose of knowing when the same computer accesses your web site again. 
Please don’t confuse this with identifying people, as that is an entirely different use of technology, which I 
don’t want to go into here. Routinely, cookies keep records of sessions, track multiple visits across days or 
months, and are even used to store login information (somewhat foolishly, IMHO). What I would propose 
is that a cookie used by a bank (and accessible only to the bank) can be used to identify a computer, 
or at least a particular browser on that computer (and as most people don’t routinely swap browsers, it 
effectively identifies a computer) Then, if the bank were to notice (which would first require they open their 
eyes) that a large number of hitherto unrelated accounts are all being accessed from the same computer, I 
would have thought that might be a little suspicious. Wouldn’t you? Moreover, if the computer in question 
appears to be somewhere outside of Australia, then it might not be the best idea to let said PC keep logging 
in to more and more accounts... Is it just me who sees this? Further, as the bank should be able to tell 
if this is one of the handful of computers you usually use to access your account, even other machines in 
Australia (or apparently in Australia, but that’s another thing) should cause a raising of alertness in the 
bank’s systems to the possibility of fraudulent activity. 
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So far, and as we continue, the legitimate users of internet banking have not had to see any change in 
the way they interact, or been forced to jump through pointless hoops to “make the system more secure” 
for them... read on. 

Going back a step or two to IP addresses, and following on from the point about the PC’s usually used. 
The IP addresses usually used don’t change much either. Even on dialup lines, the same netblock is used, 
as the addresses come from a pool owned by the ISP. So, when, for the last 12 months my account has been 
accessed from the same IP address (assigned to my cable modem by Optus), I would think that the bank 
should regard as suspicious any login attempt coming from anywhere else. Simply by using the system, 
I have demonstrated a clear pattern that ought to be noticed by an observant service provider and taken 
into consideration when a large withdrawal request is made. 

Similarly, if, for the last 12 months, my internet banking has (90% or more of the time) been done 
between 8pm and 10pm on a weekday, a sudden shift to 3am Sunday morning really ought to ring alarm 
bells (figuratively speaking). Now I’m not saying that there is no chance this is a legitimate login, but 
taken in conjunction with all the other factors discussed above and below, even a computer should be able 
to figure out if something phishy(!) is going on. 

What’s more, if there is nothing at all wrong with a login from Nigeria, at 3am, on a Sunday, requesting 
a transfer of 100% of my money to an account in Lagos, then it can still go ahead, but given the reservations 
the bank really ought to have about such a request, they could easily send me an email (at the address 
they have on file for me) letting me know about the request and asking me to contact the bank by some 
other means (other than a login) to confirm it. I could phone, reply to the email, fax with a signature. 
Given the likelihood of the transaction being fraudulent, this would make the bank look really good, no 
matter whether it was genuine or not. It’s basically just good service. And it doesn’t have to be done 
every time, just when there is good reason to be suspicious. 

Further, for the ultra paranoid internet banking customer, it ought to be possible to introduce a delay 
on outbound transfers. While this delay is in progress, notification of the pending transfer can be sent to 
the customer by email giving them time to contact the bank if they did not authorise it. The bank would 
love this as it means they get to hold the money longer. Provided the customer has sufficient time to 
contact the bank, the transfer can be cancelled without any harm. It also gives the bank and the customer 
immediate evidence that the account login details have been compromised so appropriate steps can be 
taken to fix it. I would certainly like to have the option, but it has never been offered to me. It doesn’t 
even have to be all transfers either. It would certainly be a pain if I had an urgent bill to pay and I couldn’t 
do it for 24 hours. But if it is someone I have never paid before, an amount which seems quite high, or 
just odd for any of the reasons listed above, send it through the tarpit. If it is a payee on my payee list 
to whom I regularly make payments (like the phone or gas company) and it’s about the same order of 
magnitude as usual, it’s most probably fine and doesn’t need the same checks applied. 

In short, behavioural analysis can yield a great deal more information about what is normal, and what 
is not. By behavioural, I mean, when you bank, where you bank, where your money comes from, where 
it goes to, and in what sort of amounts it usually moves. These factors will be different for everyone, but 
far from making the system harder to build, it actually makes it easier. Think about it. Your behaviour 
is unique (though seen on a larger scale, it could be classified into a number of categories). It is this very 
uniqueness that should alert the bank to strange goings on. While behaviour x may be quite normal for 
ABC corporation, it is most certainly not normal for Mrs Jones, of Smithtown. So find out what normal 
is, and look for it! Don’t just try the one size fits all approach, and wonder why it doesn’t suit anyone. 
Just because you have to wait until after something has happened to determine whether it looks normal, 
doesn’t mean it’s too late to stop it. 

The days of random hackers poking around for fun are gone. The big threat these days is the organised 
criminals. So, make it hard for them, not the genuine customer. As described above, a computer or IP 
which appears to be accessing a large number of accounts really ought not be given access to any more. 
Having determined that the computer is doing something dodgy, restricting access to the system for just 
that machine should be really simple. Even better, the machine should not have its access restricted, but 
any transactions it performs should be treated with the highest level of caution. Using this technique, the 
hackers themsleves will tell the bank exactly which accounts they have compromised, allowing the bank to 
fix the problem without any money changing hands. Let the bad guys do you a service. Basic self defense, 
turn the attacker against himself, little effort required. Many years ago I worked as a sysadmin at a girls 
school. I oversaw the administration of school policy with regard internet surfing. It was easy, watch the 
proxy logs to see where the students were actually surfing, and block those sites which violated policy. 
Rather than attempting to create a universal block list all on my own (an impossible task) I simply let 
the girls show me what I should block. I had 800 willing and very helpful assistants and I didn’t have to 
pay them a cent. Simple, effective, fast. Pretty much all of the block lists available for download were for 
porn sites, but that was not the problem. I never had to block a single porn site, the girls simply weren’t 
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interested. I did, however, have to block several thousand chat sites. All these girls wanted to do when 
they got internet access was talk to each other... 


Risk is relative 

Next thing. Risk is relative. What do I mean by that? I mean Q: Is $1000 a lot of money? A: It 
depends who you ask. To me, $1000 transfer out of my account is a big deal. To BHP Billiton, it probably 
isn’t. Ergo, risk is relative. There are many ways to determine whether $1000 is a lot of money from the 
customer’s perspective, but perhaps the simplest one is to look at the individual account for the average 
balance, credits and debits and how often money goes in and out of the account. If my average outbound 
transfer is around $150, and $1000 transaction is (literally) 1 in a 100, then there is a high risk (but not a 
certainty) that this transaction will be a big deal to me. In that case, I would like to think that the bank 
would be paying close attention to it. So, if, after years of slowly building up my balance to the princely 
sum of $10,000, the whole lot gets tranferred in suspicious circumstances, I’d like the bank to tell me about 
it before sending the funds off to some foreign bank. It may be legitimate, but then again, it may not, the 
likelihood can be quantified, so it really should be. 

If it suddenly became harder and took longer the more money you tried to steal, the number of 
professional criminals doing it might drop a little, but the fact is, at the moment, it’s really easy to take 
the entire contents of an account without question. All you need is the username and password. Adding 
a token to that list won’t slow the thieves at all, as they still get to do anything they like once they are 
inside. The inside of your account is like the inside of the bank, and the bank really ought to be paying 
more attention to what goes on inside their own systems. There need to be rules for what you can do 
inside the account, and those rules need to take into account the likely behaviour of normal legitimate 
account holders, and the likely behaviour of thieves. Once they look, the bank will find the two behave in 
very different ways. It is hard to steal $1,000,000 simply by doing what you and I do every day with our 
accounts. 


Summary - what to do 

• Restrict IP addresses outside Australia 

• Restrict odd times of day (or at least be more vigilant) 

• set cookies to identify machines 

• record IP usually used 

• record times of day usually accessed 

• record days of week/month 

• send emails when suspicious activity is detected 

• lock accounts when fraud is suspected 

• introduce a delay in transfers out - for suspicious amounts, longer 

• make care proportional to risk 

• define risk relative to customer, not bank 

Summary - lessons 

• Choose the battle ground, don’t assume you have to fight on the phishers terms, (ie. on the user’s 
PC, it is owned by the phishers I’m afraid) 

• Risk is relative 

• Genuine customers behave differently to thieves 

• Don’t let the bad guys know you are onto them explicitly. 
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• Present the same interface for illegal IPs/cookies/times as for legal ones, and use it to gather in¬ 
formation on compromised accounts. If the username and password match, for something coming 
from an illegal address, mark it as compromised and take appropriate action. Concentrate the effort 
on exceptional behaviour, and you can give much better service, eg. ring someone, you have their 
number after all. 

• Assume the bad guys will attack more than one account 

• Don’t assume the bad guys will give up easily 
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Abstract 

This paper introduces the issues of portability for C applications between Unix variants, including semantic 
differences in libraries and system calls, API support and reasonable minimum platform requirements. It 
also describes the approach used by Portable OpenSSH to the problems of secure portability and points to 
some areas where more work is needed by platform vendors. 


Introduction 

This paper introduces issues of portability for C applications on Unix, GNU/Linux and Windows/cyg- 
win platforms, including semantic differences in libraries and system calls, API support and reasonable 
minimum platform requirements. It also describes the approach used by Portable OpenSSH [16] to the 
problems of secure portability. Finally it points to some areas where more work is needed by platform 
vendors. 

Software running on modern Unix-like systems must deal with innumerable differences in libraries and 
in system behaviour. Significant differences are evident even between the various GNU/Linux distributions. 
This variance ranges from the trivial, such as differing filesystems layouts, though to the complex, such as 
platform-specific authentication methods or differences in system call semantics. 

Coping with these differences adds complexity to applications, making them more difficult and much 
less enjoyable to develop and verify. Some of these differences have serious security implications and 
the additional complexity required to cope with them also increases the likelihood of security probl ems 
Another confounding factor is that the best APIs (from a security perspective) do not have wide platform 
support, indeed some platform maintainers have actively militated against their adoption. 


Approaching Portability 

Some projects include portability as an original, explicit requirement or goal, but the majority of software 
packages are not written to be portable. Rather, they have portability incrementally added after the 
software has been developed on an original “golden” platform (usually either an explicit target platform, 
or whatever the developer likes or has available). This is not necessarily a bad thing - it provides a reference 
against which the correct operation of other platforms can be measured. 

In the case of OpenSSH, the original platform was OpenBSD, though some portability code from 
the legacy ssh-1.2.x code-base was retained. OpenSSH differs from many other software projects in its 
separation into “core” and “portable” versions. The OpenBSD developers want a clean code-base, free of 
portability clutter as the canonical home for OpenSSH is their CVS tree. The portable version of OpenSSH 
is maintained by a semi-separate team of developers in a separate CVS tree. This arrangement creates 
some extra work, as changes to the core version must be periodically merged, but automated tools render 
this process trivial and the existence of the OpenBSD version has proved useful many times in determining 
whether bugs in the core product, the portability code or the new target platform. Table 1 lists the 
platforms that are supported by portable OpenSSH. 

Most software projects, however, maintain a single version that supports multiple platforms, usually 
with some leaning towards a favourite (e.g. most recent free software projects implicitly prefer GNU/Linux). 
In either case, portability becomes an issue when developers encounter a difference between platforms. 
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AIX 

DragonflyBSD 

QNX 

Apple MacOS X 

HP/UX 10.x, 11.x 

SCO OpenServer 5 

BSDi 

Irix 5.x, 6.x 

SCO UnixWare 

Cray Unicos 

Linux 

SNI ReliantUNIX 

Cygwin 

LynxOS 

Solaris 2.6, 7, 8, 9, 10 

DEC OSF/1 

NCR SVR4 MP-RAS 

Sony NewsOS BSD 

DGUX 

NeXTSTEP 

SunOS 4 

Darwin 

NetBSD 

Ultrix 

FreeBSD 

OpenBSD 



Table 1: Platforms supported by portable OpenSSH 


At this point, it is worthwhile to consider some goals of portability. The prime objective is to have the 
software carry out its desired function(s) on the desired platforms. However, there are several less obvious 
goals: 

1. To retain readability of the code 

2. To ensure that the software behaves similarly on different platforms (including avoiding the intro¬ 
duction of platform-specific bugs) 

3. To facilitate the addition of support for new platforms 

4. To minimise maintenance costs for developers of the software 

5. To minimise support costs from users of the software 

Achieving one of these goals should not involve trading off against the others. Indeed, focusing on 
the prime objective generally makes the others much easier to achieve, though it may require a little more 
up-front effort. In addition, porting software can expose hidden assumptions and bugs that may only occur 
rarely on the base platform, finding and fixing these issues improves software quality as a whole. 

Platform differences 

Differences between Unix and Unix-like platforms are far less painful today than they were a decade, or even 
five years ago. Beyond differing endianness and word sizes, hardware differences are largely transparent to 
the modern developer. Likewise C compilers are generally feature-compatible, with the major difference 
being the command line options required to compile and link a program. System libraries are largely 
standardised and tend to include popular functions, regardless of the lineage of the particular platform. 

Spare a thought for the brave developers of twenty years ago who had to contend with differences at 
every level [9]: in the C compiler and tool-chain (still in a state of flux), in the network stack (changing 
as the TCP/IP protocols were refined), in an OS still in a stage of rapid evolution and in strange (by 
today’s standards) features and limitations of the underlying hardware that were not abstracted away by 
the underlying OS. 

However, portability issues remain; platforms are by no means homogenous. Deep differences, includ¬ 
ing subtle but critical differences in semantics exist between some systems. New APIs are being added 
frequently to both free and proprietary operating systems. 

Trivial differences 

Most platform related differences are trivial in nature. Table 2 mentions several of this nature and basic 
ways to deal with them. While these issues do not pose much of a problem to an aware developer, they 
can become more tricky to deal with through their composition. 

Use of the C preprocessor 

While the trivial differences are relatively easy to work around they can, because of the frequency of their 
occurrence, also be the ones that pose the greatest threat to readability of source code. Despite strong 
recommendations to the contrary [18], an all-too-common approach to fixing these differences is the liberal 
use of preprocessor directives to create an in-line replacement. 

These inline replacements have a tendency to multiply, leading to a maze of platform-specific code 
wrapped up in deeply nested pre-processor logic. For example, listing 1 shows a section of ntpd’s [14] 
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Problem 

Solution 

Differing system integer byte orders 
(endianness) 

Use POSIX ntohl, ntohs, htonl, htons functions to convert 

Different word sizes (e.g. of the int 
type) 

Use width specified types, such as int32-t where word size mat¬ 
ters 

Missing type definitions (e.g. 
u.intSZJ ,) 

Include replacement definitions in header file 

Missing functions (e.g. daemon, 
strlcpy) 

Include portable replacements 

Different underlying integer types 
for OS provided types, e.g. uid-t 

Cast to wider type in printf, avoid direct use as array index or 
in pointer arithmetic (avoiding signed vs. unsigned bugs) 


Table 2: Some common trivial platform differences 


startup code where the simple action of becoming a daemon has been rendered nearly unreadable by a 
maze of compatibility fall-backs. 


ifdef HAVE.DAEMON 
daemon(0, 0); 

else /* not HAVE.DAEMON */ 


/* HMS: What about a -1? */ 


if (forkO) 
exit(0); 

{ 

#if !defined(F.CLOSEM) 
u_long s; 
int max_fd; 

#endif /* not F.CLOSEM */ 

#if defined(F_CLOSEM) 

/* 

* From ’Writing Reliable AIX Daemons,’ SG24-4946-00, 

* by Eric Agar (saves us from doing 32767 system 

* calls) 

*/ 

if (fcntl(0, F.CLOSEM, 0) == -1) 

msyslog(LOG_ERR, "ntpd: failed to close open files(): */,m"); 
#else /* not F.CLOSEM */ 

# if defined(HAVE_SYSCONF) && defined(_SC_OPEN_MAX) 

max_fd = sysconf(_SC_OPEN_MAX); 

# else /* HAVE.SYSCONF && _SC.OPEN.MAX */ 

max_fd = getdtablesizeO ; 

# endif /* HAVE.SYSCONF && _SC.OPEN.MAX ♦/ 

for (s = 0; s < max.fd; s++) 

(void) close((int)s); 

#endif /* not F.CLOSEM */ 

(void) open( H /", 0); 

(void) dup2(0, 1); 

(void) dup2(0, 2); 

#if defined(HAVE.SETPGID) I I defined(HAVE.SETSID) 

# ifdef HAVE.SETSID 

if (setsidO == (pid.t)-l) 

msyslog(LOG_ERR, "ntpd: setsidO: %m"); 


# else 


- 1 ) 


if (setpgid(0, 0) 

msyslog(LOG_ERR, "ntpd: setpgidO: 

# endif 

#else /* HAVE.SETPGID I I HAVE.SETSID */ 


%m") ; 


Listing 1: excerpt from ntp-stable-4.2.0a-20050303 ntpdmain() function 


A far better approach for situations like this is to provide a replacement for the missing API ( daemon() 
in this case) and to include it in a compatibility library. This clears the main code paths of inessential 
clutter, thereby making them far easier to read and follow. Removing the clutter is also conducive to better 
security by making it easier to audit for problems. 

By locating the replacement function in a compatibility library, it will be available to every discrete 
program in the software distribution, obviating the need for each to implement its own replacement. This 
approach should be recursively applied to the compatibility functions too - merely refactoring the previous 
example into a daemon() function in a separate file doesn’t produce the full benefit unless the whole tangle 
is unwound. 

Of course, some preprocessor is almost always required - the goal is to avoid nesting it, which leads to 
an exponential growth in the number of paths through the code. As a rule, consider breaking code out 
whenever there is a need for more than one level of preprocessor nesting. 

In many cases, an even more simple solution to the issue of replacing missing functions exists: import 
or adapt code from one of the BSD operating systems. The BSD code is well written, released under a 
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liberal licence intended to facilitate exactly this type of reuse and is standard (for many functions it is the 
original and canonical implementation). Another major benefit is that this code is actively maintained, 
thus saving effort for application developers who integrate it. Portable OpenSSH makes extensive use of 
OpenBSD’s standard library code to supplement missing or broken implementations of functions on other 
platforms. 

This approach of direct replacement works well for platform functions, types and pre-processor defines 
that are missing, but it can be difficult to replace a platform supplied function that is broken. Prototypes for 
various functions differ between systems and, unless the application developer is willing to ship multiple 
prototypes for the replacement functions, it is impossible to make them work across all the necessary 
platforms. One such case is the RFC 3493 [6] address-family independent host and address lookup routines. 
Several platforms have shipped incomplete or buggy implementations of these routines that needed to be 
worked around, but direct replacements ran into the problems described above. The solution used by 
portable OpenSSH is to use the pre-processor to internally rename the functions to point to internal 
replacements (as shown in Listing 2). This approach is slightly ugly, in that it renames a system provided 
API. Another solution would be to introduce a wrapper API, but this would sacrifice some readability for 
the vast majority of systems where these functions work correctly. 


#ifndef HAVE_GETHAMEINFO 

#define getnameinfo(a,b,c,d,e,f,g) (ssh_getnameinfo(a,b,c,d,e,f ,g)) 
int getnameinfo(const struct sockaddr *, size_t, char *, size_t, 
char *, size_t, int); 

#endif /* !HAVE_GETNAMEINFO */ 


Listing 2: avoiding a buggy system-provided function 


Activating replacements 

Once a replacement function has been written or imported, the developer is now faced with another 
question: how is this replacement triggered? There are several popular approaches to this, each involving 
some tradeoffs. 

The most simple way to trigger platform-specific replacements is to use pre-processor definitions set by 
the user. These usually appear either in a Makefile or some configuration header. While this is very easy 
for the developer, it can be confusing for non-technical users and therefore likely to increase the number of 
support requests if the software is shipped as source code, though grouping together coherent sets of options 
by platform can reduce this burden. Another problem is that it can be difficult to manually maintain the 
list of definitions as the software grows more complex. If there are only a handful of defines, then this may 
be a useful solution for very small software packages. 

This method can be trivially automated using the pre-processor definitions set by the compiler or system 
include files. For example, #if defined(_0penBSD_)). This improves over the previous technique in that 
it needs no end user adjustment for the common cases. It is also easy for the developer: understanding 
which sets of options are set on a platform simplifies debugging. Unfortunately this method tends to 
become unwieldy when many platforms are added. It also fails to detect variants of a single OS, e.g. 
differences between Linux distributions. 

A better approach is to provide pre-configured sets of consistent options in the build infrastructure (e.g. 
Makefiles, automatically selected by system architecture, OS and/or the user. A good example of this is 
the imake [5] system used by X11R6 and its set of per-platform definitions files. Again, this is simple for 
the user, so long as they fall into the set of provided platforms and offers determinism for the developer. 
Supporting the software on a new platform, or variant of an existing one does take some developer time. 

Perhaps the most common approach today is to automatically detect platform characteristics by running 
compile-time tests, a la GNU autoconf [11), though this approach predates autoconf by many years [18). 
This is simple and automatic for the user, and the same system can provide a standard and user-friendly 
way of making other compile-time customisations, such as selecting installation paths. This approach 
also offers a reasonable chance that the software will work unmodified on new platforms or on variants 
of existing platforms, thereby reducing support requirements. The big problem with this method is that 
it makes it difficult for the developer to ascertain the exact configuration parameters selected on a given 
system, if they don’t have direct access to it. This makes debugging quite a bit more difficult in these 
cases. Also, the most popular tool (GNU autoconf) is somewhat fragile and therefore can be a source of 
complexity in itself, though this is not an inherent problem of the approach. 

Most free software projects use either of the last two methods, or a combination of both. Portable 
OpenSSH uses a combination, by way of GNU autoconf: compile-time tests where possible, with some 
per-platform definitions. The per-platform definitions are required because some things are difficult to 
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test. It is impractical to test for bugs in the networking functions in a general sense (what happens if the 
user is not connected to a network when running the tests?) and some other feature tests would require 
root to function. In portable OpenSSH, per-platform defines are usually used to mark certain platform 
features as “broken” and to enable platform authentication code. 


Complex differences 

Complex differences can be frustrating for the developer. One of these is a collection of essentially trivial 
differences: the wild variation between platforms in how login records are maintained. Most systems 
maintain some form of utmp (logged in users, indexed by TTY), wtmp (record of login and logout events), 
btmp (record of failed login attempts) and lastlog (per-UID record of most recent login activity) files but 
the fields present in the files, their contents and the way that login applications are expected to write to 
them frequently differ between platforms. Some platforms have adopted the POSIX utmpx format and 
associated functions, but this support is not universal even among actively maintained operating systems. 

OpenSSH introduced the logicrec API (contributed by Andre Lucas) to deal with this morass, logicrec 
presents a high-level API that hides the gory details of updating the appropriate files from the main 
application behind simple functions to record a login or logout event. To achieve this, the loginrec.c code 
needs to present a superset of the fields present in supported platforms utmp files. Compare figures 3 and 
4. GNU/Linux possesses a fairly complete utmp structure that closely matches the loginrec API, whereas 
other platforms often omit one or more fields, often the IPv6 address. This API has greatly simplified the 
task of supporting new systems in portable OpenSSH and has subsequently been adopted by at least one 
other free software project [10]. 


struct logininfo { 


char 
int 

short int 

int 

int 

char 

char 

char 


progname[LINF0_PR0GSIZE]; /* name of program (for PAM) */ 
progname_null; 

/* type of login (LTYPE_*) */ 

/* PID of login process */ 

/* UID of this user */ 

/* tty/pty name */ 

/* login username */ 

/* remote hostname */ 


type; 
pid; 
uid; 

line[LINFO_LINESIZE]; 
username[LINFO_NAMESIZE]; 
hostname[LINFO.HOSTSIZE]; 

/* ’exit.status’ structure components */ 

int exit; /* process exit status */ 

int termination; /* process termination status */ 

unsigned int tv_sec; 
unsigned int tv_usec; 

union login_netinfo hostaddr; /* caller’s host address(es) */ 

/* struct logininfo */ 


Listing 3: main loginrec.c structure 


struct utmpx 
{ 

short int ut_type; 

_pid_t ut_pid; 

char ut_line[_UT_LINESIZE]; 

char ut_id[4] ; 

char ut_user[_UT_NAMESIZE]; 

char ut.host[__UT_H0STSIZE] ; 
struct _exit_status ut_exit; 

long int ut.session; 
struct timeval ut_tv; 

_int32_t ut_addr_v6[4]; 

char _unused[20]; 


/* Type of login. */ 

/* Process ID of login process. */ 

/* Devicename. */ 

/* Inittab ID. */ 

/* Username. */ 

/* Hostname for remote login. */ 

/* Exit status of a process marked 
as DEAD.PROCESS. */ 

/* Session ID, used for windowing. */ 
/* Time entry was made. */ 

/* Internet address of remote host. */ 
/* Reserved for future use. */ 


Listing 4: Linux utmpx structure (abridged) 


A related approach is used in portable OpenSSH’s audit system (designed and implemented by Darren 
Tucker). If the platform supports login event auditing, a simple bridge can be written between its native 
API and portable OpenSSH’s abstract audit event API. At present, BSM auditing is supported as used 
by Sun and Mac OS X/OpenBSM, but other schemes would be trivial to add. Similarly, the password 
authentication / encryption code has per-platform hooks for OS vendors who have decided that they should 
make things complicated for application developers by using a function other than crypt () to perform 
password encryption. 

Some inter-platform differences are more subtle, an example of this is the differing semantics of signal 
delivery: whether system calls are restarted after delivery of a signal or whether they return with an EINTR 
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and whether or not signal handlers are reinstalled after they are used. OpenSSH uses a wrapper function 
mysignal() to provide BSD-like semantics, following the technique presented by Stevens[19]. 


mysig_t 

mysignalCint sig, mysig.t act) 

{ 

struct sigaction sa, osa; 

if (sigaction(sig, NULL, &osa) = -1) 
return (mysig_t) -1; 
if (osa.sa_handler != act) { 

memset(&sa, 0, sizeof(sa)); 
sigemptyset(&sa.sa_mask); 
sa.sa_flags = 0; 

#ifdef SA.INTERRUPT 

if (sig == SIGALRM) 

sa.sa_flags 1= SA_INTERRUPT; 

#endif 

sa.sa_handler = act; 
if (sigaction(sig, &sa, NULL) == -1) 
return (mysig_t) -1; 

> 

return (osa.sa_handler); 

> 


Listing 5: Replacement for signal() using POSIX sigaction() 

Astute readers may note that the OpenSSH mysignalf) function is not exactly like Stevens’ in that it 
does not activate the restart of system calls after receipt of a signal. This is because setting the POSIX 
SA_RESTART flag is not sufficient to ensure that a system call will fully complete upon receipt of a signal, 
for instance a read() may return fewer bytes than were requested when it is interrupted. OpenSSH needs 
to be careful here, as a SIGCIILD or other signal could arrive at any time during its execution, and it 
cannot afford to assume that a read() or write() will continue to completion. Instead, OpenSSH deals with 
interrupted or short reads and writes using a wrapper function atomicio(). This function will try to read 
or write the specified number of bytes, restarting if the system call returns a short transfer or an EINTR 
error, atomicio will run until either all the requested bytes are moved or an error or EOF condition has 
occurred. 

Differences with security implications 

Most of the time inter-platform differences will cause obvious failures when they are not properly dealt 
with. However, some differences are subtle and have effects that can seriously impact security. 

One example of this is the PAM library [17]. PAM provides a standard API for programs to perform 
user authentication, authorisation and session setup. However and ambiguity in the specification leads to 
a nasty bug. PAM is a challenge/response API, providing the application a set of pam-message structures 
which can instruct it to display messages or prompt for user input with character echo enabled (for non¬ 
sensitive questions) or disabled (e.g. for passwords). Developers of some Sun-derived PAM implementations 
interpreted this set of messages as being passed as a pointer to an array of struct pam-message, whereas the 
Linux-PAM [15] developers took the view that it is passed as An array of pointers to struct pam-message. 
In the common case where only a single message is present, the two are equivalent. However when multiple 
messages are present, an application expecting the wrong behaviour could read to or write from an incorrect 
address, a behaviour that is potentially exploitable by an attacker to gain control of the process. Worse, 
because it is responsible for authentication, the application code that deals with PAM must run with 
super-user privileges, which a successful exploit would gleefully inherit. 

To tackle this, portable OpenSSH implemented the accessor macro shown in Listing 6 to hide the PAM 
implementation’s pam-message passing convention. 


#ifdef PAM_SUN_CODEBASE 

# define PAM_MSG_MEMBER(msg, n, member) ((*(msg))[(n)].member) 
#else 

# define PAM_MSG_MEMBER(msg, n, member) ((msg)[(n)]->member) 
#endif 


Listing 6: Working around different PAM semantics 

Another platform difference of concern is in the semantics of the setuid family of calls: setuid , setreuid, 
setresuid, and their group ID manipulation counterparts. Chen and Wagner [3] have found that several 
naive usage patterns of these system calls can lead to an incomplete revocation of privilege. Portable 
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OpenSSH adopts their recommendations, and implements a somewhat paranoid approach when perma¬ 
nently discarding privilege: 

1. Drop group privileges: setgroups, setegid and setgid 

2. Drop user privileges: seteuid and setuid 

3. Try to restore group privileges and raise a fatal error if successful 

4. Try to restore user privileges and raise a fatal error if successful 

Where possible, the setresuid and setresgid API is used in favour of separate calls to set the real and 
effective IDs. These functions offers the most unambiguous semantics and ensure that saved IDs are set 
correctly [3]. As a result, OpenBSD is replacing all uses of these older functions to permanently drop 
privileges with calls to setresuid and setresgid throughout its code-base. 


Choosing the right API 

A popular, but naive view of portability is that it consists of “avoiding unportable APIs”. This may ease 
some of the more trivial portability problems encountered by developers, but it has the negative effect of 
dumbing software down to the lowest common denominator. Nearly all of the best APIs from a security 
perspective are incompletely portable. However the benefit for using these APIs in favour of more portable, 
but less secure ones greatly outweighs the cost of having to include portable replacements, especially when 
one considers that the better APIs are only going to become more common with time. 

One concrete example of this is the closefrom system call (atomically close all open file descriptors 
numbered above a certain bound) - it was first introduced in Sun Solaris, but subsequently added to 
OpenBSD and then NetBSD. An application that used the lowest common denominator approach of 
manually closing file descriptors would never benefit from the improved API, even if it was introduced to 
the application’s native platform. 

A system interface that went the other way is the /dev/random cryptographic random number de¬ 
vice [20]; first implemented on Linux and the BSDs, but eventually added to Solaris. This is a kernel 
facility that provides a central pool of cryptographically unguessable random numbers, made available to 
user applications via the /dev/random device node. Unguessable random numbers are critically important 
for cryptographic applications such as key generation and agreement. The provision of a central and strong 
API removed the temptation for application developers to “roll their own” random pooling and seeding 
code, often with insecure results [7]. The use of such kernel facilities where available, or a good user-level 
replacement (such as PRNGd [8]) is strongly recommended. 

Sadly, sometimes better APIs aren’t always universally adopted. For instance, the strlcpy and strlcat 
functions [13]. These are designed to replace strcpy, strcat , stmcpy and stmcat. These latter functions 
are standard POSIX, but suffer serious deficiencies: strcpy and strcat do not check the boundaries of the 
target buffer and therefore can easily overrun it if used without the highest degree of care (giving rise to 
the famous stack-smashing attack [2]). The bounds-checked stmcpy and stmcat are not much better; they 
fail to nul-terminate the target string if the source string is equal or longer in length than the target buffer 
(thereby opening a related class of security bugs) and they do not return enough information to allow the 
application developer to detect cases where a string truncation has occurred. 

The strlcpy and strlcat API properly check the target buffer’s bounds, nul-terminate in all cases and 
return the length of the source string, allowing detection of truncation. This API has been adopted by 
most modern operating systems and many standalone software packages, including OpenBSD (where it 
originated), Sun Solaris, FreeBSD, NetBSD, the Linux kernel, rsync and the GNOME project. The notable 
exception is the GNU standard C library, glibc [12], whose maintainer steadfastly refuses to include these 
improved APIs, labelling them “horribly inefficient BSD crap” [4], despite prior evidence that they are 
faster is most cases than the APIs they replace [13]. As a result, over 100 of the software packages present 
in the OpenBSD ports tree maintain their own strlcpy and/or strlcat replacements or equivalent APIs - 
not an ideal state of affairs. 

Finding replacements for good APIs isn’t hard - it is highly probable that a free software project has 
already solved the problem and has made a licence-compatible replacement available. Nor should the task 
result in a dramatic increase in a project’s size, most of these APIs are trivial to replace. Table 3 shows 
the sizes of the largest replacement functions used in portable OpenSSH. In almost all of these cases, the 
code was obtained or adapted from OpenBSD’s standard C library. A good long-term approach in this age 
of open source operating systems is to also contribute this support code to their libraries or kernels. 
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Function 

Lines of code 
(inc. comments) 

glob() 

914 

snprintf() 

652 

getrrset by name () 

585 

base64_ntop() and 
base64_pton() 

324 

getcwdQ 

242 

vis() 

239 

inet_ntop() 

229 

getaddrinfo(), 
getnameinfo() and 
support functions 

224 

openptyQ 

201 

realpathQ 

196 


Table 3: largest replacement functions in Portable OpenSSH 


Conclusion 

The main recommendations of this paper may be briefly summarised into six simple rules: 

1. Avoid cluttering main code paths with portability code, especially that wrapped up in nested pre¬ 
processor 

2. Pick the best possible API available, even if it isn’t available on every platform - it can be replaced 
or imported if it doesn’t exist somewhere 

3. Replace missing or broken functions in a separate library rather than performing the surgery inline 

4. Where possible, obtain an existing, known-good replacement instead of developing new code (e.g. 
from OpenBSD’s libc) 

5. When dealing with areas of great platform variability, abstract the API back to a superset of the 
platforms’ features 

6. Be alert for subtle differences or bugs between platforms, and doubly so in areas of an application 
that wield privilege 

This paper has detailed some common portability problems, ranging from the simple to the complex, 
and approaches to solve them. These approaches may not be optimum for every application, but they 
have served portable OpenSSH well in allowing it to function on over twenty platforms while retaining 
maintainability of the code-base. 
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Abstract 

In this paper, we describe a series of legal challenges and problems we encountered during the last five years 
of working with Linux. We describe common problems faced when building corporate services offerings 
based on Linux open source technology. We will present an overview of a couple of basic open source 
licenses as well as their main ideas and applications. We use a hypothetical situation to describe legal 
challenges and how we believe they can be overcome. 


Introduction 

Today most large corporations are involved in Open Source Development (OSD) and development of 
applications that rely or use parts of open source. Commercial products can work cooperatively with OSS 
in many situations. One can say that corporations are generally incorporate OSS, when it makes business 
sense. Corporate developers of Open Source face lots of problems and dangers. We have to deal with the 
fact that OSS as such, causes a lot of additional problems for making the final product available. 

In this paper, we are talking about a hypothetical situation where Linux is critical in the service 
offering being provided. The company providing this service offering perceives that it is a significant 
risk to incorporate and utilize Linux technologies with accompanying licenses. The perceived risks of 
shipping Linux make it impossible for the company to directly distribute Linux and any other open source 
technologies. In order to provide the service offering, the company must provide a way of allowing the 
partner to install its offering while not directly distributing open source. 

To highlight the issues related to open source distribution, we review some popular examples of open 
source licenses and their perceived risks/strengths. We then present a solution to our hypothetical situation 
that allows these risks to be mitigated. 

OSD Licenses and related challenges 

As developers we have to deal with OSS in cases [1] when we: 

• Use open source code in products (source or binary formats) 

• Join an existing open source project 

• Start a new company-sponsored open source project 

• Distribute any company-written code (e.g., reference implementation, product) in source form under 
an OSS license (e.g., GPL) 

• Provide services involving a distribution of software involving Open Source 
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What this means for the typical developer is a lot of headache. Any project involving OSS most likely 
needs to manage multiple OSS licenses. Any shipping and distribution of code containing OSS needs to 
be ratified by corporate councils and product owners, which decide if the product/solution/code snippet’s 
value outweighs the associated risk. To further complicate matters corporations have to decide [2], if they: 

• Offer third party branded shrink-wrap OSS to be shipped as part of a bundle with the company’s 
own hardware, software and/or service offering. Since the company ships individual components and 
leaves the installation of these components to the user, the company feels removed from the risk. 

• Preload a subset of a third party Linux distribution on hardware and ship full third party branded 
Linux distribution on separate media “in the box”. By installing only a subset of the distribution, 
the company can selectively approve the associated risk of this subset. The user may be required to 
install additional components from the separate media to complete the intended solution. 

• Distribute third party OSS (usually unbranded), to the customer in binary form with or as a part of 
corporate product. This may require making the source code freely available. This option is usually 
not available to companies that refuse to accept perceived risks associated with OSS distribution. 

• Distribute software or hardware products to the customer that is procured from a third party vendor, 
which includes third party OSS. This can also cause problems because often the third party does not 
provide indemnification. 

To complicate things even further, there are different licenses used in OSS. In making an integrated 
solution you will run into technologies associated with multiple licenses. Corporations desire to protect 
their interests often goes against the main idea of OSS. There are many different licenses out there since 
many companies write their own. Most of company specific licenses are in some form related to the couple 
of basic licenses [2] such as: 

• GNU General Public License (GPL) and GNU Lesser General Public License 

• BSD license 

• MIT license 

• Mozilla Public License (MPL) 

The “classic” licenses, GPL, LGPL, BSD, and MIT, were the most commonly used for OSS before the 
Mozilla release in early 1998. The MPL has since become widely used. 

GPL is the most common, since it is the underlying license for most of Linux. GPL gives users three 
big rights: they can copy or redistribute the software, change it in any way desirable, and it makes the 
source code accessible. The main requirement is that the users/coders/companies pass on these rights, 
to other users. What this means for programmers is rather simple; any changes to the code must be 
distributed in source code form as well. It is not acceptable to distribute an application and not distribute 
the source. Most users don’t really care about the source code and don’t care to receive it. Most users 
prefer precompiled run-able packages. According to the GPL, source doesn’t have to be distributed with 
every copy of the product but has to be made available and the user must be told how to obtain it. The 
GPL license has to be shipped with every GPL’d product. A very important point in the GPL license is 
that companies can charge for the distribution costs of the program and source code. The GPL protects 
GNU libraries from being incorporated into proprietary software and also protects proprietary libraries 
from the “tainting” of the GPL. This also brings us to the big issue surrounding the GPL, which is the 
“viral” effect. The basic idea is that any code combined with the GPL code must be reissued under the 
GPL license. Most corporations see this as a bad thing since it exposes their code to the public and use 
this as the main reason against using the GPL. 

The biggest difference between the GPL and the Lesser General Public License is in the fact, that 
the LGPL permits laxer criteria for linking other code with the library. This license provides other free 
software developers less of an advantage over competing non-free programs. The Lesser license provides 
advantages in certain special circumstances. For example, on rare occasions, there may be a special need 
to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve 
this, non-free programs must be allowed to use the library. A more frequent case is that a free library 
does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free 
library to free software only, so in these cases the Lesser General Public License [4] is used. 

The BSD License allows programmers to decide whether or not to provide the source code of their 
programs with the software. This is a major change when compared to the GPL license, which requires 
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Figure 1: The development organization will integrate all the components of the system and make them 
available to the business partner. The business partner will need to replicate and tailor the system for all 
of its customers. 


developers to provide source code upon request. The BSD license is more flexible for programmers and 
corporations since it provides a degree of protection for the source code. One large problem with the 
BSD license is related to its advertising clause, which was used originally only in the Berkeley Software 
Distribution. That did not cause any particular problems, because including one sentence in an ad is not 
a great practical difficulty. Unfortunately other developers did not copy the advertising clause verbatim. 
It got changed replacing “University of California” with many different names. The result is a plethora of 
licenses, requiring a plethora of different sentences [3]. This clause was removed in the latest version of the 
BSD license. 

MIT License is a very simple, free, non-restrictive license compatible with the GPL. Any person ob¬ 
taining a copy of the software covered with the MIT license is allowed to deal with the software without 
restriction. They have the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
copies of the Software as well as permit persons to whom the software is provided to do same. The only 
condition is that the copy of the license has to be provided with the software. It’s a very simple and often 
used license. 

Rarely do open source licenses provide warranties or indemnities, which contribute to the perceived 
risks. Confirming the origin of the contributed open source code may also be a problem. 


A technique for risk mitigation 

In this section, we will describe a hypothetical (typical) problem that corporate Linux developers face. 
Let’s assume we want to develop a Linux appliance that will provide a rich set of integrated services to 
standard Windows clients. This appliance is a Linux server running a tailored set of integrated proprietary 
and open source applications. Business partners who use it to provide services to their customers will 
distribute the appliance. The following diagram illustrates these relationships: 

To complicate matters, our hypothetical development organization is not able to distribute Linux com¬ 
ponents covered by the GPL license because of the perceived risks. At the same time, business partners 
may not have the knowledge and experience to install an appliance like this. The appliance needs to be 
delivered to the partner as a turnkey solution. This creates conflicting problems: the development orga¬ 
nization needs Linux but can’t distribute it; and the business partner needs the end solution but doesn’t 
know how to build it from components. This means that the development organization will have to create 
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Figure 2: Package distribution on the web 


a rather ingenious installation process that will automatically build and tailor the appliance at the business 
partner’s site. 

Our solution is based on the observation that all needed open source components are available on the 
Internet. The first step is to provide the business partner with the Linux environment to use. There are 
many simple yet highly efficient distributions on the market that can simplify the installation of Linux on 
the initial machine at the business partner’s site. Distributions such as Red Hat, Suse, and Debian are 
too complicated to install and are avoided. Much simpler live CDs such as Knoppix [5] work great for our 
hypothetical example. Knoppix comes in form of a bootable live CD. It is freely available on the Internet 
and has a large set of applications and libraries including the complete development environment for Linux 
on the CD. This development environment makes it highly suitable for our purpose. 

The beauty of using a live Linux bootable CD medium as a first installation step is that the operating 
environment is always the same and unchanging. When the partner boots the CD on the appliance device 
to be installed, the partner can use the web browser to download and run the tailored install script from 
the development organizations website. At the business partners site the installation script will connect to 
the developments organizations web site and after authenticating itself download non-open source modules. 
Once this step is finished additional open source modules will be downloaded from the web. Keeping track 
of additional modules we need for our solution is then just a matter of good bookkeeping and making sure 
they are available on the web. The final integration of all modules is taking place at the business partner 
site and the development organization is protected from all perceived risks associated with shipping open 
source. 

The downloaded OSS and non-OSS components are best provided in form of a RPM or DEB packages. 
That makes them trivial to install and upgrade should upgrades become necessary. The build environment 
package can be downloaded from development organizations website since it is not GPL-ed and doesn’t 
contain any programs or code that is GPL-ed. The install of the OSS and non-OSS components can be 
done seamlessly in the initial live boot CD environment without any extra reboots. 

An important part of delivering the appliance to a business partner is the ease of installation and 
deployment. If the business partner wishes to mass produce appliances, a cloning procedure rather than 
individual installation may be more effective. Developing a simple cloning method can make installing 
second, third and n-th machine much faster. There are several ways a machine like this can be cloned; 
using one of the off-the-shelf applications such as Ghost will result in any number of identical machines. 

The install script itself can be as complicated as needed since it always runs in the same environment 
that is specified by the development organization and installed by the business partner. Non-OSS must be 
compiled and packaged inside the development organization because it is proprietary in nature. This means 
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Figure 3: A series of steps performed as part of creating the initial installation at business partner site 

you will not download non-OSS on the build machine at the business partner site and have it compiled as 
part of the build process. This in turn means that all applications and libraries that development corpo¬ 
ration wishes to keep non-OSS need to be compiled at the development organizations build machine and 
made available on the web as executable object code. This way the build script can download and install 
them on the business partners build machine. This provides the development organization with the protec¬ 
tion of source code for applications and the business partner with a standard way of upgrading/installing 
the system. 

Below we show the diagram of these steps: 
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Figure 4: The complete process flow 

Another important consideration we have to deal with is that of updating packages once they have 
been delivered to the business partner or end customer. If for the package distribution we use simple tar 
files, it becomes difficult to upgrade packages. If we use DEB files to distribute packages, package updating 
is simplified. The standard built in package management tool (dpkg/apt-get) is used in order to provide 
version management. 
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Summary 

In this paper we present a novel and simple way for a large corporation to distribute Linux based products 
and solutions in accordance with its licenses while maintaining ownership of its own code and applications. 
We present a typical example and environment that developers and project managers face when developing 
a server/client type of a system. We present a business process, which can be used to distribute, build, 
and deploy such a solution. This work is in progress and funded by IBM and Lenovo. 
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Abstract 

This paper presents a description of a mid-range services gateway that uses Linux as an internal infras¬ 
tructure. A range of subjects are discussed, such as security issues, multi-CPU interaction, distribution, 
performance and scaling. The architecture of the NetDevices SG-8 is described, with emphasis on the 
technical aspects of employing Linux as the underlying infrastructure, and the benefits and costs involved. 

,4 s part of this infrastructure, a networking subsystem is described that addresses the major issues 
with supporting a sophisticated and extensive packet processing environment on Linux without sacrificing 
performance or robustness. 


Introduction 

Traditionally, routers are developed using proprietary operating systems (such as Cisco’s IOS), or by 
licensing an OS from a vendor (such as QNX, or VxWorks etc). With the growing acceptance of Linux as 
an embedded or targeted OS, it is becoming more common to see Linux being used in this environment. 
In fact, with the networking support that is built in to Linux, a common arrangement is to use the 
networking facilities of Linux wrapped with some friendly and vendor specific user interface. There are 
significant advantages to using Linux in an embedded environment, such as cost, portability, access to 
source etc. Sometimes, however, the developer can fall afoul of the GPL if careful consideration is not 
taken e.g the Linksys situation, where using Linux internally also meant that code tainted with the GPL 
must be freely offered when that code is used in a publicly available application. NetDevices Inc. is a 
Silicon Valley startup founded in 2003 with the goal of developing a next generation services gateway, 
incorporating routing, firewall, VPN and other networking applications in a single integrated device. This 
paper describes the experience in implementing this device using Linux as an internal framework, but 
without using the Linux networking facilities directly. 


Environment Overview 

The NetDevices SG-8 is a state-of-the-art services gateway that incorporates many different networking ap¬ 
plications in a single integrated device, offering a high degree of manageability, performance and robustness. 
Physically, the SG-8 consists of a number of separate hardware hot- swappable modules, interconnected 
with a high speed industry standard PCI- Express bus. A unique feature is the introduction of a cluster 
of management orientated CPUs, separating the management functions of the device from the control and 
data plane. These CPUs communicate via an internal high speed LAN: 

Internally, there are a number of different CPUs, some with functions related to the management 
facilities of the device (providing user interface, CLI services, configuration, monitoring etc.), and some 
dedicated to packet processing and control plane functions (route protocol processing etc.). Linux is running 
on each of these CPUs, and provides the infrastructure framework that hosts the various applications 
running internally. These applications provide the router and gateway functionality. Linux provides the 
following facilities: 

• An embedded kernel, providing the usual kernel/user process model. 

• Internal network connectivity, for communication between the various CPUs in the device. 
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• A familiar and well understood environment for hosting applications. 

• The ability to run the same applications on a host PC for development and testing. 

• The readily available open source packages that can be run on Linux with no change, such as em¬ 
bedded web servers, SSH servers and clients, SNMP agents etc. 

Given the widespread availability, portability, and cost of Linux, it is of no surprise that it is rapidly 
becoming the preferred environment for embedded systems. 


External/Internal View 

Whilst Linux is being used internally on the SG-8, to all intents and purposes the user of the system will 
never be aware of this fact, nor will the user be exposed to any specific Linux user interface or Linux utility. 
Even though the device is being used to process network packets, none of these packets are processed using 
the Linux networking facilities. 

Instead, a NetDevices proprietary packet switching framework is used to provide the packet processing 
applications. This framework is called NetIO, and forms the basis of the data and control plane of the 
SG-8. 

As can be seen, NetIO is a Linux kernel module that interacts with a user process, so that the packet 
processing is actually performed in user space rather than kernel mode. NetIO device drivers are used 
to provide the physical device interface. There are a number of advantages to this approach, such as 
robustness, performance, and modularity. 

An internal Ethernet is used for the interconnection of the various CPUs in the system, so that manage¬ 
ment and control information can flow around the system (no packets being forwarded through the system 
ever appear on this internal network). For ease of addressing, a simple lO.x.x.x addressing scheme is used. 

Externally, however, the device is treated as a ‘single system view’, so that external users and network 
peers interact with the device just as if it were a single host with multiple interfaces (just like any other 
router). More importantly, there is a strong isolation and decoupling between the internal view of the 
system and the external view, for obvious security and robustness reasons. 

The interesting implication that arises from this external/internal decoupling is that very extensive 
network applications and features can be implemented entirely according to the user applications running 
on the system, irregardless of whether Linux itself supports these features, or has anything to do with 
them. Conceptually, this model can be viewed as creating a virtual router operating internally over a set 
of CPUs running Linux. This has a number of advantages: 
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• The external addressing and interface management are entirely separate from the addressing of the 
internal LAN, so that there is no overlap or mixing of traffic. 

• Performance is highly scalable by the use of multiple data plane CPUs, or offload CPUs, that are not 
externally visible. 

• Sophisticated network features can be much more easily implemented, such as Virtual Routing and 
Forwarding (VRF), where multiple routing and forwarding domains can coexist within the device 
without any impact on the internal addressing. 

• The system can be more robust, with the failure of individual elements not being visible externally 
e.g if one management CPU fails, then another can provide the same services. 

• A more isolated and secure separation is achieved between the key internal facilities and the external 
packet traffic. 


External view 

Virtual Router 


Management 

Management 

Control/Data olane 

CPU 

--—I 

CPU 

CPU 


This model of separation between the internal and external view of the system has been successful in 
delivering these advantages. 


Management Gateway 

Given that there is now a separation between the external view of the system (and how packets get in and 
out of the device), and the internal network, how does this impact applications, especially applications 
that use the standard Linux networking facilities (such as sockets etc.)? If I want to run an application like 
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a SSH server using the standard OpenSSH application, how does it interface internally so as to be visible 
in the external view of the system? 

This is achieved through the use of a facility called the Management Gateway (MG): 



The MG is the bridge between the external view of the system, and the internal applications that provide 
the management facilities of the system. When an application is to be accessed from external packets, it 
will use a MG API to register itself. The MG will interact with the data plane to register the UDP/TCP 
port number associated with that application. Meanwhile, as part of the application initialisation, the 
application will open and listen on a socket on the internal LAN. The application can be running on the 
same CPU, or a different CPU, as the MG. 

When packets arrive for that application, the data plane will forward the packets to the MG. The MG 
will perform a Network Address Translation on that packet to map the packet address to the address of an 
internal tunnel interface, and forward it to the application’s listening socket via the tunnel driver (used to 
deliver a user level packet into the kernel networking stack). Packets sent from the application will be sent 
back to the tunnel interface, where the MG will receive the raw packet, perform the appropriate reverse 
NAT, and forward the packet to the data plane for transmitting. 

The application may need to discover the peer address of the connection. If it used the standard socket 
function (getpeeraddress), it would see the internal address of the tunnel interface, rather than the real 
external address. So the MG API provides facilities for the application to discover the peer address, port 
number and other context (for AAA or other purposes). 

The MG performs a critical role in mapping the external network interfaces into the internal applications 
so that standard applications can be used with very little modification. The MG will perform a range of 
functions: 

• Knowledge of the various external network interfaces and IP addresses attached to these interfaces. 

• Awareness and mapping of multiple routing domains (VRFs) so that applications can use the internal 
network for interacting with potentially overlapping private routing and addressing domains (part of 
the MG API is to provide VRF information for the application if it requires it, something that is 
unavailable through the stock Linux kernel. 

• Security filtering of application packets, so that Denial of Service attacks will not impact the man¬ 
ageability of the device. 

• Load balancing when multiple instances of the application may be running on multiple CPUs. 


GPL Issues 

As a lawyer quoted in a presentation when advising NetDevices concerning the GPL, lawyers generally hate 
the GPL because it is so clear and watertight in its treatment of Open Source - they would much prefer 
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a BSD style license, which is quite different in its commercial applicability. It is interesting to discuss the 
various considerations that needed to be taken into account when actively developing in a mixed proprietary 
and GPL environment. Care must be taken to avoid tainting GPL source with proprietary code (either 
because the code is separately licensed, or being internally developed), and to maintain strict boundaries 
and awareness of the areas where the GPL applies. 

One approach that is used in the NetDevices system is to run specific GPL programs as separate 
processes, using standard IPC mechanisms to present the data for processing. For example, the use of 
Snort as an Intrusion Detection System is very common, so that many customers and users have developed 
a high degree of trust in this tool. There is significant advantage to be able to employ such a tool as an 
internal process incorporated seamlessly into the main packet processing of the system by running Snort 
as a process on one of the data plane CPUs, and internally passing packets to it for processing. In this 
way, there is no violation of the GPL, and customers can use the best tool for the job, externally seamless. 

In some areas where it may be somewhat grey, it is easier to simply provide various interface libraries 
or code and make it Open Source to avoid any kind of GPL taint. The Linksys experience shows that 
commercial organisations ignore the GPL at their peril, and will quite correctly be taken to task for any 
kind of violation or license issue. Netdevices position is that the GPL should be honoured in every situation, 
and pains are taken to ensure that no licensing boundary is crossed. 

Part of the approach here is that it can be shown that in a larger system or environment, GPL and 
proprietary code can co-exist quite easily as long as care is taken to ensure the appropriate boundaries 
are maintained; of course, there is the wider issue of whether all code, proprietary or otherwise, should be 
Open Source, but the commercial reality is that this is not a goal that will be achieved. 

One interesting implication is the acceptance in the startup community of Linux and Open Source 
in general, to the extent that most Venture Capital providers are well aware of Open Source, and the 
significant advantages it holds. The Open Source environment has become well wired into the DNA of the 
general software engineering community. 


Conclusion 

The NetDevices SG-8 is an interesting product because it successfully employs man y of the advantages of 
using Linux and other Open Source product, whilst providing a sophisticated and fully featured networking 
device. 

The use of a decoupled external/internal view of the networking processing has successfully allowed 
a greater degree of scalability, performance, security and robustness. The use of Linux as an internal 
framework for an embedded system has delivered many significant benefits, such as speed of development, 
testing, and application portability. 
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About the Internet Analysis Report — 2004 

As someone who has been involved with the international growth of the Internet since the mid 1980’s, 
and with Internet governance bodies in both professional and volunteer capacities, I have been concerned 
for some time that some of the organisations which are governing and managing the Internet have not 
evolved sufficiently to deal with the problems which have appeared as the Internet gets older and bigger. 
I first heard the Internet protocols described as legacy systems in the 1990s, but, like most people, took 
no notice and got on with the business of growing it. However, by the turn of the century cracks were 
beginning to appear. These cracks became larger and larger during 2003, to the point where it became 
clear to me and others, that something is wrong. At the same time as some of us were becoming concerned 
with the technical issues, the World Summit on the Information Society was beginning to debate Internet 
governance - certainly not an unrelated topic. However, here another concern was evident to me: much 
of the governance debate was proceeding without full knowledge of what Internet governance actually 
involves. My company, Ian Peter and Associates Pty Ltd, works professionally with large governmental 
and private sector organisations that have problems with organisational structures and old IT systems and 
uses established project and change management methodologies to analyse associated issues. It seemed to 
us to be appropriate to use these methodologies to look at today’s Internet systems, governance, and user 
issues. 

Searching the literature, we were surprised to find that traditional business analysis appears not to have 
been applied to Internet matters. As a result, we commissioned the Internet Analysis Report - 2004, of 
which this is the Executive Summary. The Internet Analysis Report - 2004 is a comprehensive study of the 
state of the Internet in 2004. It contains an in-depth analysis of issues facing Internet users, emerging issues 
with Internet protocols, governance bodies and governance issues, and conclusions and recommendations. 
Reviewed by a panel of international experts, the report has been highly praised. Pull details on obtaining 
a copy of the report can be obtained at http://www.internetmark2.org/ 


Problem Definition 

Introduction 

The Internet was developed in the 1970s and 1980s, initially as a means to connect mainframe computer 
systems for timesharing purposes. The system introduced for this fairly basic purpose has expanded to 
become a global multimedia information and communications system, connecting personal computers, 
phones, and hundreds of millions rather than the hundreds of devices originally foreseen. Some of the 
significant developments not foreseen at the time of the original design include: 
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• The development and widespread use of networked personal computers 

• The use of phones and portable devices on the Internet 

• Broadband networks and processing power 

• A network to be used for commercial purposes 

• The World Wide Web. 

Parts of the system are now over 20 years old, and the Internet is required to perform a number of 
important functions not included in the original design. New protocols have been developed, and various 
patches have been applied to base protocols, not always evenly. It seems appropriate to examine whether 
the current system, people, and processes are still appropriate. Although it is clear that the system which 
has evolved is extraordinarily useful and needs to be continued, it is not clear whether the current Internet 
effectively meets its user’s needs, on either a technical or a managerial level. 

Issues 

The Internet currently has some 600 millions users, or about 10% of the world’s population. Although 
usage is still growing rapidly, both socio-economic and technical issues would appear to be slowing the 
overall growth rate. Some of the major user issues appear to be: 

• The high incidence of viruses and worms arising from security weaknesses, giving rise to tens of 
billions of dollars of expenditure annually in an attempt to prevent damage 

• A rapidly developing lack of trust in the system, caused by fraudulent use of addresses, non-existent 
companies, and the ease with which criminal activity can go unchecked 

• A clogging of email systems with “spam”, or junk email, most often emanating from fraudulent hosts 
and email addresses 

• Issues as regards use that does not meet normal societal standards of behaviour 

• Perceived “slowness” from a users point of view in accessing sites 

• Limited availability in many parts of the world 

• Affordability issues, particularly in developing countries 

• Availability issues, particularly those pertaining to the ability to communicate via the Internet in 
native languages. 

These and other significant issues are threatening the usefulness of the Internet. Preliminary analysis 
suggests that some significant improvements are both needed and possible, but not necessarily easily dealt 
within the current structure. Some of the reasons given include: 

• Perceived inertia in the technical management and development by the Internet Engineering Task 
Force (IETF), giving rise to lack of faith among major players 

• Perceived weaknesses in the management and governance structure 

• Perceptions that the Internet has become a tool of US Government policy. There is a lack of easy to 
read material analysing the current state of the Internet. There is also a lack of comprehensive user 
and business analysis. The Internet Analysis Report 2004 addresses these needs. 

Scope of study 

Objectives 

The key objectives of the Internet Analysis Report - 2004 are: 

• To conduct a comprehensive business analysis of the Internet at the end of 2004, as an aid to 
determining future directions and strategies 

• To produce a factual document giving the history and the current state of development of the Internet, 
to guide thinking about future directions 

• To investigate the major user requirements for a 21st century Internet 

• To initially analyse whether the current Internet is capable of meeting these objectives. 
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Summary of findings (Executive Summary) 

History 

Contrary to common opinion, neither the Pentagon nor 1969 hold up as the time and place the Internet 
was invented. A project which began in the Pentagon that year, called Arpanet, gave birth to the Internet 
protocols sometime later (during the 1970’s), but 1969 was not the Internet’s beginnings. 

Larry Roberts, who was employed by Bob Taylor to build the Arpanet network, states that Arpanet 
was never intended to link people or be a communications and information facility. Arpanet was about 
time-sharing. 

Time sharing tried to make it possible for research institutions to use the processing power of other 
institutions computers when they had large calculations to do that required more power, or when someone 
else’s facility might do the job better. It never really worked as an idea - for a start, all the computers had 
different operating systems and versions and programs, and using someone else’s machine was very difficult: 
but as well, by the time some of these problems were being overcome, mini-computers had appeared on 
the scene and the economics of time sharing had changed dramatically. 

So it’s reasonable to say that ARPANET failed in its purpose, but in the process made some significant 
discoveries which were to result in the creation of the first Internet. These included email developments, 
packet switching implementations, and development of the Transport Control Protocol - Internet Protocol 
(TCP/IP). TCP/IP, the backbone standards which many people claim are the basis of determining what 
the Internet is, were developed in the 1970s in California by Vinton Cerf, Bob Kahn, Bob Braden, Jon 
Postel and other members of the Networking Group headed by Steve Crocker. 

The sort of computers Arpanet was dealing with had very little power by today’s standards. Only 
computer scientists used them. Computers with the power of modern day pocket calculators occupied 
whole floors of buildings. These monsters could only be afforded by large institutions. 

It would take until the late 1970s for the personal computer to appear. Even so, for personal computers 
as well as mainframes, communication with other computers, and particularly other brands of computers, 
was an afterthought. It probably took the decade from 1983 to 1993 before anything like a sensible situation 
for computers to connect to the Internet emerged. 

Ray Tomlinson is credited with inventing email in 1972, but in fact email is much older than that. Like 
many of the Internet inventors, Tomlinson worked for Bolt Beranek and Newman as an Arpanet contractor. 
He picked the @ symbol to denote sending messages from one computer to another. So then, for anyone us¬ 
ing Internet standards, it was simply a matter of nominating <username>@<hostcomputername>. Email 
soon became the Internet’s first “killer application”. 

In many ways, Internet adoption was about the path of least resistance. In the beginnings, governments 
wanted a completely different set of standards called OSI - but industry and governments could not agree 
on the details. There was a real mess out there, and no agreement on how to get out of it. 

The dominant standards body that should have been interested in this problem was CCITT (Consul¬ 
tative Committee on International Telegraphy and Telephony) of the International Telecommunications 
Union (ITU), but they were essentially not interested in computers and software in the beginning, and 
when they did become interested, became committed to the ill-fated OSI track. So the Internet community 
had to devise its own way of dealings with standards. 

This is probably where internet governance began to grow and formalise as a unique identity. A system 
called RFCs (Requests for Comment) was set up by Steve Crocker, and out of the network of engineers 
submitting and commenting on RFCs the Internet Engineering Task Force (IETF) evolved as a standards 
body. 

Then the World Wide Web came along, and offered a much improved user interface and some substantial 
new applications. Every year from 1994 to 2000, the Internet saw massive growth. The Internet era had 
begun. The rest of the story is likely to be well known to most readers of this document. 

These origins are important to our understanding because they help to explain how the Internet evolved. 
In particular, what we discover from a basic understanding of history is that the original protocols were 
introduced for a world which 

• Had no personal computers 

• Operated at very slow speeds 

• Did not contemplate secure financial transactions 

• Did not foresee non-English language users 

• Was more concerned with computer to computer, rather than inter-personal communications 
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• Was willing to accept the trustworthiness of every participant 

• Was for use by highly skilled and economically affluent people only. 

It would be abnormal if protocols of this age and this difference of purpose were not, to all intents and 
purposes, legacy systems. 

User requirements and future needs 

Our future Internet, rather than having 600 million users, may have close to 6 billion. So we may be 
only 10-20% of the way there, and there is a lot of growth to come. This will place new demands on the 
infrastructure and the way it is held together. Those experimenting with future networks with increased 
speed are already suggesting significant problems will exist coping with the increased size, scale and speed 
of the Internet. 

The Internet Analysis Report - 2004 identifies both problems and future trends which need to be taken 
into consideration in looking at a future Internet. Problems include: 

• Identity fraud and other criminal activity 

• Spam 

• Viruses/worms 

• Exposure of children to unacceptable material 

• Hacking 

• Speed 

• Capacity to communicate in one’s own language 

• Affordability 

• Accessibility in less economically developed areas and for socially disadvantaged groups 
Some of the future issues and trends that need to be considered and which are outlined include: 

• ENUM and convergence with telephony based systems 

• the growth of wireless and mobility 

• size, scale and speed issues 

• the growth of peer to peer applications. When these and other factors are considered, a statement 
begins to emerge about tomorrow’s Internet. 

The Internet is for everyone. 

The Internet of the future must be 

• trustworthy 

• reliable 

• globally inclusive 

• vendor neutral 

• easy to use 

• affordable 

• able to change rapidly 

• innovative and capable of significant expansion 

• transparently and well managed 

• involving industry, government and community stakeholders. This statement is to be built 
on to provide a more comprehensive overview of where the Internet must go. 
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Protocol issues 

TCP/IP protocol 

TCP (The Transport Control Protocol) in particular has come in for significant criticism, and a growing 
body of experts believe it will need to be replaced. Indeed, if it were easy to replace a fundamental Internet 
Protocol, this may have been done some time ago. It’s the complexity of the change management problem 
that has delayed action rather than lack of recognised need for change. Particular issues with TCP/IP 
include: 

• Traffic prioritisation 

• Unsuitability for financial transactions 

• Security issues 

• Performance issues with larger and faster networks. 

The study concludes that TCP - if not TCP/IP - needs to be replaced, probably within a five to ten 
year time frame. The major issue to overcome is the migration issue which is discussed below. 

DNS and WHOIS 

Each host on the Internet can be located via an IP number. The Domain Name System (DNS) maps the 
numbers to names of hosts or websites (eg. www.google.com,www.hotmail.com ). Thus, when a user 
enters a name, the Internet knows which number to send the query to by looking up the DNS database. It 
should be noted that the other widespread user of distributed network infrastructure, the telephone system, 
operates quite differently. It has no domain name equivalent with trade mark implications in normal uses 
- to contact a telephone address, you simply enter the number. 

The DNS was introduced in 1984, several years before commercial traffic was able to be part of the 
Internet. At the same time, a public database called Whois was introduced, essentially to allow technical 
managers of hosts to contact their peers. This is the Internet equivalent of a telephone directory, but also 
serves a number of related purposes. 

One issue with DNS is that it has not been possible to use native languages in email addresses, domain 
names, and the WHOIS database. This poses significant barriers to adoption for non-English speaking 
people. The main problems here are that 

• ASCII (the American Standard Code for Information Exchange) is used in the DNS. ASCII is inca¬ 
pable of supporting the complexities of foreign language. 

• No-one wants to substantially change the DNS. 

Internationalised domain names (IDNs) have become a fundamental part of and an iconic symbol for 
the digital divide issue. ICANN has been criticised at its regular Public Forums for not giving the matter 
sufficient attention, failing to make significant progress, and being negative in its analysis of this issue. The 
Internet Analysis Report - 2004 examines this issue in detail. Other issues with DNS include: 

• Slow refresh rates, which pose particular difficulties with emerging standards such as ENUM and 
prohibit some interesting applications 

• Issues with WHOIS and privacy 

• Issues with security in DNS. 

These are again problems that need to be addressed in a five year timeframe at the outside - some of 
them would be best handled more quickly if possible. 

SMTP and Email protocols 

To all intents and purposes, email is already broke, and must be fixed. The Internet’s first and greatest 
killer application is now problematic. 

In a survey examining email usage in 2003, the Pew Internet Project found that 

• 25% of email users stated that the ever increasing volume of spam has reduced their overall use of 
email 



126 


INTERNET ANALYSIS REPORT 2004 - PROTOCOLS AND GOVERNANCE 


• 70% of email users claimed spam had affected the quality of their on line experience 

• 30% of users expressed fears that filtering approaches would cause loss of wanted mail 

• 76% of users are bothered by offensive or obscene content in spam email 

• 80% of users are bothered by deceptive or dishonest content in spam email. 

Costs associated with spam have been estimated by various research firms at between $10 billion 
(European Union, 2004) and $87 billion (Nucleus Research, 2003) per annum. Spam volume is now 
estimated to exceed legitimate email volume; in May 2004, 76 percent of inbound e-mails scanned by email 
security provider MessageLabs Ltd were spam, up from 67 percent a month earlier. 

ICANN claims spam issues as out of scope. .. issues of concern to Internet users, such as the rules for 
financial transactions, Internet content control, unsolicited commercial email (spam), and data protection 
are outside the range of ICANN’s mission of technical coordination” (ICANN website). IETF has been 
very slow at doing anything in this field, preferring to leave investigation of the issues to a separate Internet 
Research Task Force (IRTF) group. 

As a result, there is a general belief that nothing technical can be done to prevent spam. However, 
our analysis suggests that the existing protocols are significant contributors to the problem, and protocol 
reform could see spam volume drop by at least 80%. 

SMTP, the basic email standard, is the online equivalent of borders without checkpoints and passports, 
or bank vaults without doors and locks. Some of the SMTP security weaknesses are: 

• It allows anyone to connect with anyone without any system to say who they are 

• It is simple to forge messages and pretend to be someone you are not with no checking whatsoever 

• Not being one to one like telephone calls, it is easy to mass market to millions of email addresses at 
very low cost to the email sender. 

These issues have been known for some time. Various attempts to provide improved protocols have 
been undertaken, but essentially have resulted in a mass of conflicting systems and standards. As a result, 
change is becoming more complex to initiate. Email upgrades are complicated by 

• Old systems which are never upgraded 

• Incorrect applications of email systems 

• The variety of applying protocols (eg http for webmail, smtp, nntp, pop etc) 

• The ubiquitous nature of email 

• IETF difficulties in handling big problems. 

The Internet Analysis Report - 2004 analyses recent IETF work in this area and concludes that both 
governance issues and protocol reform need to be addressed to provide a more comprehensive solution. 

Governance bodies 

The International Engineering Task Force 

Founded in 1986, the Internet Engineering Task Force describes itself as “a loosely self-organized group of 
people who contribute to the engineering and evolution of Internet technologies specifications”. The IETF 
is unusual in that it is not a corporation and has no board of directors, no members, and no dues. IETF’s 
own internal analysis (RFC 3774 - IETF Problem Statement) has revealed significant problems, including: 

• IETF is unsure about what it is trying to achieve 

• Cannot determine what its scope should be 

• Is unsure who its stakeholders are 

• Cannot prioritise actions effectively 

• Loses sight of overall architecture. 
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IETF governance contrasts substantially with the other two standards organisations involved with 
Internet standards. ITU has the strongest governance structure, being responsible eventually to member 
state representatives, and W3C standards work is determined and prioritized by a member organization. 

So in this respect, IETF is peculiar. And this peculiarity brings with it certain problems because, in 
reality, few issues if any are purely technical and have no policy repercussions. This is shown out in case 
studies outlined in the Internet Analysis Report - 2004 where IETF of necessity has had to move outside 
its technical mandate but has not been effective in doing so. 

Two of the case studies, covering DNSSEC and IPv6, also indicate extremely long time frames within 
IETF for protocol development and implementation. No-one can attribute these long time frames to 
technical complexity alone. Poor methodologies, volunteerism, under-resourcing, unprofessional behaviour 
and management issues have all contributed to delays, according to the IETF Problem Working Group. 

IETF’s decisions to address its problems in an open forum are to be applauded, as are its attempts to 
engage a wide global audience of engineers in its consensus based decision making structures. However, 
IETF is a classic technocracy. While it appears to be reasonably capable of managing the day to day 
concerns as regards maintenance of standards, it does not have the capacity to tackle major tasks or major 
change. To solve these problems, IETF would need to 

• Have a clear relationship to a governing body with the competence and representative nature to deal 
with policy considerations which are outside the scope and expertise of IETF 

• Have means of introducing non technical skills sets such as project and change management to its 
affairs 

• Be resourced to provide dedicated rather than volunteer effort in working on major priorities 

• Have a clear scope, mission, and relationship within an overall technical management structure for 
the Internet, and with other Internet bodies of a non-technical nature which fulfil complementary 
roles in determining policy and assisting adoption of standards 

• Learn to communicate effectively with business, community and government stakeholders. 

Other standards bodies — ITU and W3C 

To an outsider, The International Telecommunications Union (ITU) appears to have all the efficiency and 
capacity to get things done that ICANN appears not to have. However, that perception may well be 
illusory; and anyone who has been involved in development of standards such as X.400 could point to 
equally problematic issues in ITU. 

It should be remembered that, at the time IETF was established in 1986, telecommunications companies 
were not major players in the emerging Internet. They became more involved from 1990 on, as a commercial 
Internet got underway. It should also be remembered that in the 1970s the US telecommunications giant, 
AT&T, could not see a business case for involvement in the Internet. This perhaps is the most telling 
criticism of the staid and solid elder statesman that ITU is - it may find it difficult to be nimble or 
innovative in seeing future directions. 

ITU, like IETF, is undergoing considerable internally driven reform to try to better cope with the 
demands of a rapidly changing communications technology landscape. There would appear to be room 
for some of the strengths of ITU to be better utilised alongside those of IETF and ICANN in the future, 
particularly as telephony and Internet based applications continue to converge. 

W3C is the third “standards body”, and effectively addresses issues with the World Wide Web archi¬ 
tecture. It separated from IETF in 1994 as it believed IETF to be incapable of dealing with its particular 
range of issues. 

ICANN related bodies 

It is important to realize that ICANN doesn’t control everything in Internet technical co-ordination. An 
interesting history associated with the early growth of the Internet led to a number of quite independent 
structures being established. These include: 

• Country domain administrators, who in many countries were early technical volunteers who have no 
formal relationship with national governments. In some developing countries, country administra¬ 
tors are located overseas and are not national citizens. Although a form of techno neo-colonialism 
remains in the administration of some country domains, and some hostility to co-operation with 
government authorities exists in others, most country domains are now forming appropriate locally 
defined relationships with their governments and their local constituencies. 
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• Regional Internet Registries (RIRs) such as APNIC (Asia Pacific) and RIPE (Europe), which were 
set up before the ICANN/US Government contract was in place and retain substantial independence 
while administering the IP numbering system. 

• Root server operators, many of them volunteers. The central root server is administered by Network 
Solutions, and any changes need the approval of the US Dept of Commerce, not ICANN. 

ICANN has a series of relationships with these separate bodies which it is attempting to formalise. 

ICANN 

The Internet Corporation for Assigned Names and Numbers (ICANN) exists in its current form largely 
because the US Government wanted it to be so. 

Its structure is an evolving reactive mechanism. Anyone analysing its current structure without regard 
for the history of how it came to be would have to regard ICANN as 

• eccentric in structure 

• illogical in scope, and 

• incomplete in terms of Internet governance. 

The initial proposal for a body to administer the domain name system suggested establishment under 
Swiss law. However at the beginning of October 1998 the US Government’s National Telecommunications 
and Information Administration (NTIA) responded to this proposal by announcing the Internet Corpo¬ 
ration for Assigned Names & Numbers (ICANN). It would operate under an agreement with the NTIA 
with oversight by the US congress. The new body was asked to ensure competition in delivery of domain 
name services. Thus ICANN became a corporation under US law, with a contract to operate from the US 
government, despite concerns of many stakeholders. 

ICANN claims its mission to be technical co-ordination. (ICANN website). However, because of the 
eccentricities and incomplete nature of Internet governance structures, ICANN has consistently worked in 
areas that cannot be regarded as technical co-ordination. 

For instance, in 1999 it succeeded in establishing a Uniform Dispute Resolutions Policy (UDRP) for 
the top level domains; hardly a technical co-ordination task, but certainly a useful one for development of 
the new media. 

Similarly eccentric is the role of ICANN in creating a competitive environment in DNS, part of its 
contract with US Department of Commerce. This would normally be seen as a regulatory body’s respon¬ 
sibilities, not a technical co-ordination task. 

Public policy matters where ICANN is active include intellectual property issues and security. Public 
policy matters where ICANN is not active include spam and consumer protection. Once again, the logic 
of involvement and non-involvement is not easy to follow. 

Perhaps partially as a result of this mission confusion, ICANN does not handle public policy well or 
effectively. An example of this was its recent attempts to gain widespread public input in to the WHOIS 
database and privacy issues. 

Governance conclusions 

The problem with ICANN, and with IETF, is one of defining scope within a schema that effectively manages 
all needs of the 21st century Internet. No such schema exists, and that is why bodies such as ICANN and 
IETF are continually operating in areas outside of their level of competence in order to keep things afloat. 

If there is a problem in Internet governance, it is the gaps between the competencies of existence 
governance bodies and the needs of Internet industry, governmental, and community users. As user needs 
in a broad sense do not come within the range of concern of any particular Internet governance body, it is 
inevitable that mistakes are being made and crucial issues are not being addressed. 

Conclusions and Recommendations 

There arc many problems facing the Internet at the current time. Those closest to each problem are making 
substantial efforts in isolation from other major issues to address their particular problems, often however 
seeking short term fixes rather than longer term solutions. A co-ordinated approach across all areas seems 
necessary for resolution. 

IETF and ICANN have been unable to deal with the range of issues and concerns adequately. This is 
acknowledged as an issue by many people who are aware of the problems. 

The question then becomes how to proceed to reform. 
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Governance reform 

The WSIS governance debate will be ongoing until at least mid 2005, and at that point of time is only 
likely to consider what governance structures should be in the future. This study acknowledges that an 
appropriate forum exists to examine governance issues, and suggests that some of the information in the 
Internet Analysis Report - 2004 might assist in discussions of how to appropriately reform governance. It is 
not simply a matter of removing ICANN from the somewhat benign influence of the US Dept of Commerce; 
it is necessary to consider the range of issues involved in creating tomorrow’s Internet as an effective and 
equitable tool for human development. That requires some refocussing of discussion to address some wider 
issues and needs. 

Protocol reform 

What is not being discussed as comprehensively is how to reform protocols. The Internet Analysis Report 
- 2004 concludes that protocol reform is necessary. 

Project management structures are both the normal and the most effective way to handle major change 
projects of this nature. A separate short term structure should be established for this purpose. It would 
consist of: 

• A dedicated full time project team, containing the best engineering, project management, research, 
change management and communications expertise available to scope and deal with this problem. 
Other skills sets will also be necessary as the project progresses. 

• A Project Steering Committee with major stakeholder involvement to review progress and determine 
direction. 

The exact makeup of both the Project team and the Steering Committee needs further investigation 
with major stakeholders. A preliminary range of potential activities and involvement possibilities are 
outlined in the full study and at www. internetmark2 . org.The entire process is unlikely to be completed in 
less than three years. There are compelling reasons to suggest it must be completed within seven. At the 
end of a successful implementation, the project would hand over responsibility to an appropriate Internet 
governance structure which will most likely have emerged from WSIS and beyond. 

It may be suggested that current Internet organisations should deal with this change. This study 
believes that would be ineffective, as: 

• They have substantial operational issues to deal with which stretch their resources 

• Their technical-only governance is inappropriate for the task 

• Volunteer structures are inappropriate 

• Their track record in handling major change in a timely fashion is not good 

• They lack the range of disciplines and the skills base for handling change of this magnitude. 

For these reasons the existing governance and standards bodies, although they should be encouraged 
to be active participants, should not be the only voices at the table for this future development initiative. 

Change management issues with protocol reform 

Knowledgeable insiders in stakeholder Internet industry companies and research institutions are aware to 
varying degrees of the need for improvement in the base protocols. However, executive decision makers at 
this stage are probably not aware of the need for reform. The Internet Analysis Report - 2004 is designed 
to assist in raising awareness, and contains a detailed analysis of the change management issues involved 
in protocol reform. 

Some large industry players may initially perceive benefit in blocking or delaying change in order to 
protect dominant market positions, or to gain opportunities from proprietary approaches. 

There will doubtless be robust debates within some industry players about the market affect of change 
in this area. 

However, market leaders will face crucial losses of markets if change does not occur within a reasonable 
time frame. Involvement in the new generation Internet will eventually be seen as a market plus; but the 
issues must be understood and clearly communicated for this to happen. 

Some defensive actions can be expected in current Internet bodies, and some feeling of loss of control 
and that they should be in charge of change. The more positive involvement of individuals who initially 
react this way is more likely in a middle adoption phase, when the project clearly has impetus. 
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Government officials from a wide variety of backgrounds will have interest in new governance structures 
and in public policy issues which may emanate from projected changes. However they will be less interested 
in the protocol issues and content to leave that to others to develop. 

Information is the key to success here. Unless the problems are recognised and acknowledged, and 
compelling reasons to effect change are understood, action to rectify the problems will not occur. 

Technical Options 

It appears necessary at this preliminary stage to look at some sort of gateway structure through which 
people pass to adopt “Internet Mark 2”. For a substantial period of time, Internet Mark 2 will need to 
coexist and co-operate with the legacy Internet. However eventually people will pass through the gate to 
the other side. 

And, although differing opinions exist, it also appears to be necessary to nominate a point in time at 
which the gates shut, and interoperability with the old system disappears. 

Other options to be examined would include a layered superstructure on top of existing protocols, or 
an overall peer to peer architecture that effectively bypasses problematic protocols gradually. 

Risks and dependencies 

The risks associated with inaction on these issues substantially exceed those involved in moving forward. 

The risks associated with delay are also substantial. 

Significant problems with base protocols are already evident. Given that the necessary changes cannot 
be implemented overnight, it is appropriate that a major effort to address these problems begin now. 

The Internet Analysis Report - 2004 concludes that there are substantial inter-dependencies between 
protocol reform and governance. The dilemma facing the Internet community is that protocol reform has 
dependencies on governance reform, but cannot await completion of reform processes. 

Protocol reform and governance reform must therefore be addressed in parallel, with some clear under¬ 
standings among all parties concerned of the need to co-operate fully in ensuring that the next generation 
protocols and the next generation governance eventually come together in an appropriate manner. 

The Internet Analysis Report - 2004 recommends some initial actions in addressing protocol issues. A 
preliminary range of funding, sponsorship and involvement possibilities are suggested at www. internetmark2 . org. 
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Abstract 


NetBSD has a cross build infrastructure which allows cross-building of an entire NetBSD release including 
bootable distribution media. The build process does not require root privileges or writable source directories. 
The build process works on many POSIX compatible operating systems. This paper explains the changes 
made to NetBSD to enable this build process, enumerates benefits of the work, and introduces future work 
enabling cross building of any software for NetBSD. 


Introduction 

NetBSD [1] is the most portable Unix operating system in common use. It is freely available and redis¬ 
tributable, and runs on a broad variety of platforms from modern desktop systems and high end servers 
that can build an entire release in less than an hour, to embedded systems and older machines that may 
take several days to build a release. 

In late 2001, work began on changes to improve the ability of NetBSD to be cross built, especially an 
entire release. This system is referred to as “ build.sh” , because that is the name of the script that is the 
user-visible front-end to the infrastructure. 

NetBSD 1.6 was the first release to be shipped with build.sh, and the Release Engineering group of 
the NetBSD Project took advantage of it to cross-build binary releases for 39 platforms on a near daily 
basis during the release cycle for NetBSD 1.6 [2J. Previous releases required access to each of the various 
platforms by release engineers, or co-ordination with developers with that hardware. While that method 
works for a moderate number of platforms (NetBSD 1.5 released binaries for 20 platforms), it does not 
scale, especially as the number of platforms in NetBSD is growing (57 as of October 2005). 


Background 

NetBSD 

Since the NetBSD project was started in 1993 it has had a goal of being portable [3] to many target 
platforms. There has been significant effort in designing, implementing, and improving NetBSD to make it 
easier to “port” to a new target platform [4]. Device drivers are written in a way that permits easy sharing 
between platforms without unnecessary code replication [5]. 

The source code portability of NetBSD did not equate to “ease of use” when building the system on a 
host other than the target platform, or indeed, natively. 

Prior to build.sh a NetBSD release for a given platform was built “natively” on that platform on a 
version of the operating system that was “close” to the target release. There were exceptions, but these 
alternate processes were not simple to use nor easily automated, and had a variety of other limitations 
which build.sh addresses. 

build, sh offers a level of flexibility in building NetBSD that has not been addressed by other open source 
operating systems. 
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Cross compiling Unix 

Unix was cross-compiled from the beginning, but when native hosting was available, that became the main 
development methodology and has remained so. 

Cross-compilation is the technique of running programs on a “host” system to generate object code for 
a different “target” system. This has not been an easy task for most system builders and has generally not 
been integrated into the operating system build processes as used by open source operating systems. 

Freely available software projects such as GCC [6] have supported being cross-compiled for a long 
time, and GCC is part of the GNU toolchain which NetBSD uses and is heavily dependent upon for 
cross-compiling. 

An introduction to cross-compiling 

There are many parts to a full cross compiler environment. Besides the compiler itself, many other tools 
and files are required to create functional programs. Everything that a normal compiler needs must be 
present. For the GNU toolchain, this includes: 

• The compiler - gcc. 

• The assembler - as. 

• The linker - Id. 

• The “binutils”; size, nm, strip, ar, etc. 

• Header files (provided by NetBSD). 

• Libraries (provided by NetBSD and the GNU toolchain) 

Following is a quick overview of how it all works. This is basically the same for any compiler; in this 
example the details are from the GCC C compiler: 

1. The C compiler front-end gcc calls the C pre-processor cpp on an input source file, usually a “.c” file, 
producing a “.i” file. This is still valid C code but will now be devoid of C pre-processor directives. 

(In modern GCC, the cpp pass is actually done inside the ccl pass to speed up the process and 
provide better error reporting. This process is largely invisible to the user.) 

2. gcc calls the back-end ccl with the output of cpp producing a “.s” file. This is an assembler source 
file corresponding to the input C file. 

3. gcc calls the assembler as with the output of ccl producing a “.o” file. This is an object file 
corresponding to the input assembler file. 

4. gcc calls the linker Id (via collect2) with the output of as plus several other object files (sometimes 
collectively called the “crtstufF’), to produce an executable. 

In addition to creating executables, archive and shared libraries are built. Archive libraries are usually 
created with the ar binutils program from a collection of object files. Shared libraries are created by 
calling gcc with the -shared option, which calls Id with various options to create a shared library. 

gee's -v flag may be used to see exactly what external programs are called. For example, cross-compiling 
a simple NetBSD/evbarm “hello world” C program on a NetBSD/i386 box gives: 

argo> /tools/bin/arm—netbsdelf-gcc -I/dest/usr/include -L/dest/usr/lib -B/dest/usr/lib -v -save-temps -o hello.x hello.c 
Reading specs from /tools/lib/gcc-lib/arm—netbsdelf/3.3.3/specs 

Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc/configure —target=arm—netbsdelf —disable-nls —enable-long-long 
—disable-multi1jb —enable-threads —program-transform-name=s,“,arm—netbsdelf-, —enable-languages=c C++ objc f77 —prefix=/tools 
Thread model: posix 

gcc version 3.3.3 (NetBSD nb3 20040520) 

/tools/lib/gcc-lib/arm—netbsdelf/3.3.3/ccl -E -quiet -v -I/dest/usr/include -isystem /dest/usr/lib/include -D—GNUC—=3 

-D_GNUC_MIN0R_=3 -D__GNUC_PATCHLEVEL__=3 -D__ARM_ARCH_3__ hello.c hello.i 

ignoring nonexistent directory "/dest/usr/lib/include" 

ignoring nonexistent directory "/tools/arm—netbsdelf/sys-include" 

ignoring nonexistent directory "/tools/arm—netbsdelf/include" 

#include "..." search starts here: 

#include <...> search starts here: 

/dest/usr/include 

/tools/lib/gcc-lib/arm—netbsdelf/3.3.3/include 
End of search list. 

/tools/lib/gcc-lib/arm—netbsdelf/3.3.3/ccl -fpreprocessed hello.i -quiet -dumpbase hello.c -auxbase hello -version -o hello.s 
GNU C version 3.3.3 (NetBSD nb3 20040520) (arm—netbsdelf) 

compiled by GNU C version 3.3.3 (NetBSD nb3 20040520). 
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GGC heuristics: —param ggc-min-expand=38 —param ggc-min-heapsize=16384 
/tools/lib/gcc-lib/arm netbsdelf/3.3.3/../../../../arm—aetbsdelf/bin/as —traditional-format -mfpu=softvfp -matpcs 
-o hello.o hello.s 

/tools/lib/gcc-lib/arm netbsdelf/3.3.3/collect2 -X -dc -dp -e __start -dynamic-linker /usr/libexec/ld.elf_so -o hello.x 
/dest/usr/lib/crtO.o /dest/usr/lib/crti.o /dest/usr/lib/crtbegin.o -L/dest/usr/lib -L/dest/usr/lib 

-L/tools/lib/gcc-lib/arm—netbsdelf/3.3.3 -L/tools/lib/gcc-lib/arm—netbsdelf /3.3.3/. ./arm—netbsdelf/lib hello, o 

-lgcc -lgcc_eh -lc —lgcc -lgcc_eh /dest/usr/lib/crtend.o /dest/usr/lib/crtn.o 

The output shows the pre-processor (“ccl -E”), back-end compiler (“ ccl ”), assembler (“as”), and 
linker (“ collects” ) programs being called in succession. An object file is created and the sundry “crtstuff” 
is added to the final linker line. 

If gcc is passed the -save-temps option the output of each program will be saved rather than deleted 
after it has been processed. In the above example, the following files were created: 


argo> Is -1 hello.? 


-rw-r- 

~r— 1 

me 

us 

96 

Sep 

27 

23:28 

hello.c 

-rw-r- 

—r— 1 

me 

us 

8437 

Sep 

28 

00:30 

hello.i 

-rw-r- 

-r— 1 

me 

us 

908 

Sep 

28 

00:30 

hello.o 

-rw-r- 

-r— 1 

me 

us 

508 

Sep 

28 

00:30 

hello.s 

-rwxr- 

xr-x 1 

me 

us 

6855 

Sep 

28 

00:30 

hello.x 


These are the source file and the cpp, as, ccl and Id outputs, respectively. 

For a cross compiler the assembler, linker and binutils must also be “cross” tools. For the GNU toolchain 
these are normally called “$target-$tool”. For example powerpc-eabi-ld is the linker for the “powerpc-eabi” 
target. 

Each cross compile environment needs to provide header files and libraries appropriate to the target 
platform. These may be provided either as a static set of files or the build process may produce them 
as part of its bootstrap. The NetBSD process uses both of these techniques for header files and builds 
libraries from source. 

Targets, hosts, and build hosts 

One part of cross compilers that is often confusing is the difference between a “target”, a “host” and a 
“build host”. These are: 


target 

The platform the toolchain creates output for. 

host 

The platform that runs the toolchain. 

build host 

The platform that builds the toolchain. 


Table 1: Cross-compiler terminology 


The three normal ways to build the GNU compiler are: 

1. A native build is when all three host types are the same: 

./configure && make bootstrap 

2. A normal cross compile is when the “build host” is the same as the “host”: 

./configure —target=powerpc-eabi && make 

3. A “Canadian cross compile” is when “build host”, “host”, and “target” are all different: 

./configure build=i386-netbsdelf —host=i686-pc-cygwin —target=powerpc-eabi && make 

This strange beast is called a “Canadian cross compiler”, because when a name was needed there 
were three prominent political parties in Canada. It is most often found when dealing with pre-built 
toolchains. The above example would produce a toolchain that will run on a i686-pc-cygwin host 
(i.e., a Windows system with Cygwin installed) and will target embedded PowerPC platforms. The 
toolchain would be built on a NetBSD/i386 ma chi ne 

A normal cross-compiler is required to build a Canadian cross-compiler. 

Most people who build software use a native build in all cases. Usually people using cross compilers 
use the same “build host” and “host”. 

The host compiler is the compiler used to bootstrap the cross compiler, and to build any other host 
tools that need to run on the build host. 
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Feature set 

The features of the build.sh system are detailed below. Other systems have addressed some of these issues 
but not all of them. 

Cross compilation of a NetBSD release 

This is a huge benefit to developers who wish to use NetBSD on a target platform (often an embedded 
system) but prefer to use a different host development system. 

This feature is dependent upon toolchain support as described earlier. 

Suitable build systems include: 

• Current and previous NetBSD releases. 

• Other Unix-like systems, such as Darwin (Mac OS X), FreeBSD, HP-UX, Linux, and Solaris. 

• Windows with Cygwin. 

Simplicity 

build, sh needs to be simple to use while retaining enough flexibility to allow advanced users and developers 
to customize their build environment. 

NetBSD has a finite amount of volunteer resources, so simplifying the build process reduces the support 
load. 

Read-only source trees 

The source tree can be read-only and can be shared between builds for different target NetBSD platforms. 
This permits building directly from read-only media or “mirrors” of source code without causing unneces¬ 
sary mirroring conflicts. In this case the build output is written to a separate writable section of the file 
system. 

The only file system restrictions on the source tree and object tree are that they must reside on a file 
system that supports case sensitive file names, and path-name length. 

Root privileges are not necessary 

No root or other special privileges are required in order to build distribution media. Previous build processes 
required privileges on a NetBSD system to create tar files or file systems that contained devices, files owned 
by other users, set-ID files, etc. 

Most other build systems require special privileges. For example, the Debian fakeroot [7] mechanism 
requires the host operating system to support shared object libraries with SLD.PRELOAD functionality 
(where a shared object is loaded after the main program but before the program’s shared object depen¬ 
dencies), and this breaks the next requirement. 


Avoid non-portable OS features 

Prior to build.sh, the creation of NetBSD boot media required root privileges to create a “loopback vnode 
disk device” ( vnd ), install boot blocks, create a file system on the vnd, mount the file system, and create 
file system entries owned by the non-building user. Most other systems still build their distribution media 
in this manner. 

build.sh does not require host operating system features such as: virtual disk devices, loopback file 
systems, chroot cages, shared objects/libraries, or dynamically loaded modules. 

Segregated build tools 

build.sh builds “host” tools to STOOLDIR. which is a location separate to the host system’s native tools. 
build.sh uses the tools in STOOLDIR to build the NetBSD system installing to a separate SDESTDIR 
location. This removes the “chicken & egg” problem that can occur when the host platform’s in-tree tools 
would need to be upgraded to build a newer source tree. 

The older technique using the in-tree toolchain had the drawbacks: 

• Without massive contortions, the build host had to be running NetBSD of the same architecture and 
similar software vintage. 
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• The in-tree toolchain required periodic updating. 

• Updating the in-tree toolchain often required special handling that could not be easily automated. 
For example, at one time /usr/share/mk needed an updated make , and at another time make needed 
/usr/share/mk to be updated. 

Minimize impact on NetBSD source 

There was minimal impact on the existing NetBSD sources and build infrastructure. 

We did not want to change the NetBSD source tree to support being built by foreign compilers. Ac¬ 
cordingly the host’s native toolchain is only used to build the NetBSD host tools. 

It was necessary to improve the portability of the NetBSD host tools to non-NetBSD platforms. These 
changes were not significant. 

Don’t special-case cross-compiles 

It was a requirement that build, sh was usable for native builds as well as for cross compiling. 

This feature is another component of the effort to reduce the support overhead of building NetBSD, 
whilst retaining our desired flexibility. 


Results 

Benefits 

Regular automated builds 

During the NetBSD 1.6 release engineering process, 39 platforms had near daily builds of the base operating 
system release, ensuring that at least all build problems were well known every day, and that up to 
date builds were available for testing by anyone. The majority (37) of these builds were performed on 
a dual processor AMD MP2000+ machine generously donated by AMD and Wasabi Systems, and the 
NetBSD/alpha and NetBSD/sparc64 releases were built on Matt Thomas’ CS20 alpha. 

This contrasts with the NetBSD 1.5 release where 20 platforms had a binary release; all of them were 
built natively on the particularly port, requiring each port to have a dedicated person to build it, with 12 
days time from when the first port was finished and available to the last port. 

The NetBSD 2.0 release expanded the number of platforms built in this manner to 50, which included 
the addition of the cross-building of X11R6. NetBSD 3.0 will ship with 53 platforms, and NetBSD-current 
has 57. 

As of October 2005, the “autobuild” infrastructure for NetBSD comprises of four dual Opteron build 
hosts, and these build three release branches in parallel per day. 

Simplicity of use 

The new build.sh is very simple and easy to use, yet powerful. Anybody can build a kernel, userland or 
full release for most platforms on the fastest machine they have available. 

More portable source code 

It has identified every tool in NetBSD used for building. We know what tools we need and what features 
these tools must support. We had to make sure these tools were portable programs that would build and 
run correctly on other platforms. 

Cross-platform builds 

We no longer require running a particular version of NetBSD in order to be able to build it. Building 
NetBSD 3.0 from a NetBSD 1.6 machine is supported, as is building from Solaris, Linux and more. Gone 
are the days of source build bootstrap problems that had plagued NetBSD since day one. 

Costs 

Teething problems 

build.sh took a long time to settle down and be stable and useful. On the other hand, adding new platform 
support is no deal now, as this is a one time cost that has been paid. 
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Cross-unfriendly software 

Much software is written without consideration to cross compiling and thus makes it very difficult to 
cross compile. Not only the way the software itself is written, but the way the software is actually built. 
Many software build processes build helper programs to generate real code, and so these programs must 
not only work correctly for the target system rather than the native system, they must be built by the 
“host” compiler. The automounter amd was affected by this, as the build process assumed the local 
host architecture was the same as the program being built, causing a NetBSD/sparc binary built on 
NetBSD/i386 to incorrectly byte swap data into little endian for processing. 

CPU endianness and word size issues 

Endianness and CPU word size issues within the toolchain can cause problems. Due to bugs in the version 
of GCC that was used in NetBSD 1.6 (2.95.3), NetBSD/alpha for that release could not be cross compiled 
from a 32-bit host, and NetBSD/i386 could not be cross compiled from a 64-bit host. 

Fortunately these issues were solved by GCC 3.3, which is the version of the compiler we used for 
NetBSD 2.0. 

Overhead in converting a platform 

Not every platform has been converted to build.sh yet. In some cases (e.g., NetBSD/pc532, NetBSD/- 
playstation2) the in-tree toolchain does not support those platforms in the build.sh framework, whilst in 
others the platforms may not have had a complete build infrastructure before build.sh was integrated, 
and there were limited resources prior to the NetBSD 1.6 release. Most platforms were converted for the 
NetBSD 2.0 release. 

Performance implications 

There is a time cost in compiling the host tools, but it is not considered significant enough to pose a 
problem. For example, on an AMD XP2500+, the times for the various methods of building a NetBSD/i386 
1.6 release were: 


Time to build tools with build.sh: ./build.sh -U tools 

5m 6s 

Time to build a release with build.sh: . /build, sh -U release 

lh 28m 

Time unsuccessfully spent attempting to make release with the old build process 
on a two month old system, which failed due to problems with out-of-date tools. 

> 2h 


Table 2: Performance Comparison 


Implementation 

The implementation of the build.sh infrastructure comprises of a variety of elements. 

The build process uses various environment variables to control its operation, including: 


TOOLDIR 

Pathname to host tools for a given host platform. 

DESTDIR 

Pathname to built NetBSD system. 

RELEASEDIR 

Pathname to resulting NetBSD release files. 


Table 3: build, sh environment variables 


src/build.sh 

build.sh is a Bourne shell script designed to build the entire NetBSD system on any host with a POSIX 
compliant Bourne shell in /bin/sh. It creates a directory for various host tools uses to cross build the 
system (referred to as STOOLDIR), creates a “wrapper” to make to pass in various settings, builds the 
host tools with the make wrapper, and uses the host tools to build the rest of the system, into a staging 
area referred to as SDESTDIR. 



IMPLEMENTATION 


137 


build.sh is very flexible and can be used to build an entire release, a specific kernel, just the tools or 
make wrapper, or even upgrade the installed system from a previously populated SDESTDIR. 

The order of operation of build.sh is: 

1. Validate arguments including the target platform (which defaults to the host platform) which is stored 
in $'MACHINE, and the target machine (CPU) architecture which is stored in $MACHINE_ARCII. 

2. Build a host binary of make and install as $TOOLDIR/bin/nbmake. 

3. Create the “make wrapper” shell script that contains various (environment variable) settings which 
control the build and install as $TOOLDIR/bin/nbmake-$MACHINE. (This may be the last operation 
performed for this invocation of build.sh.) 

4. Build the host tools to generate the binaries for the target SMACIIINE and install under STOOLDIR, 
with the executable host binaries available in STOOLDIR/bin. 

5. Perform any other operations requested using the STOOLDIR host tools, including: 

• Build a NetBSD distribution into SDESTDIR. 

• Build all the kernels for a specific NetBSD release and package those and the contents of the 
SDESTDIR into a release under SRELEASEDIR. 

• Build a specific kernel. 

• Create the release “sets” from SDESTDIR or the source “sets” from the source tree. 

• Upgrade a directory (usually “/”) from SDESTDIR. 

Certain SMACHINE platforms support more than one $MACHINE_ARCH CPU architectures (a bi- 
endian processor or are processor with more than one word size are considered to be separate CPU machine 
architectures), and build.sh supports building the different target CPU architectures as separate releases. 

src/BUILDING 

In-tree documentation for build.sh. 

src/Makefile 

This Makefile at the top-level of the source tree contains various targets to facilitate building the entire 
NetBSD source tree, including: 


build 

Build the entire NetBSD system, in an order that ensures that 
prerequisites are built in the correct order. 

distribution, build world 

Perform ‘make build’ and then install a full distribution into SDESTDIR, 
including the contents of SDESTDIR/etc and SDESTDIR/var. 

sets 

Build “sets” from the distribution in SDESTDIR. 

release 

Perform ‘make distribution’, then builds kernels, distribution media, install 
“sets”, and then packages the system under SRELEASEDIR 

installworld 

Install the distribution from SDESTDIR to SINSTALLWORLDDIR 
(which defaults to “/”). 


Table 4: Top-level Makefile targets 


src/share/mk 

To simplify the build process, NetBSD uses a library of make Makefile include files (with the suffix “.mk”) 
in src/share/mk. This was inherited from the 4.3BSD Networking/2 and 4.4BSD Lite releases, and has 
been significantly enhanced in the decade since. 
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src/tools 

Traditionally, BSD systems are built using in-tree tools, compilers, include files and libraries. This isn’t 
usable for cross-compilation, and has many other problems which this new infrastructure fixes. 

src/tools contains the make infrastructure required to build various host tools used during the build. 
These tools are built using an autoconf-built compatibility frame-work, and use “reach over” Makefiles into 
the rest of the NetBSD source tree to minimize replication of code. The source code for these host tools 
have been slightly modified to allow them to be built in as a normal NetBSD (target) program, as well as 
a host tool. 

The host tools are installed into STOOLDIR, and the BSD make “.include” infrastructure in 
src/share/mk selects the various host tools in preference to the “standard” versions. For example, for a 
NetBSD/i386 target $CC will be set to $TOOLDIR/bin/i386-netbsdelf-gcc instead of cc. 

There is support for using an external toolchain rather than the in-tree versions of binutils and gcc. 
This is useful when there isn’t yet support in the in-tree toolchain for a target platform. 

The host tools currently consist of: 

as asnl-compile binutils cap^mkdb cat cksum compile.et config crunchgen ctags db dbsym diskla- 
bel fdisk file gcc gencat groff hexdump install installboot Id lex lint lorder m4 make makefs 
makewhatis mdsetimage menuc mkcsmapper mkdep mkesdb mklocale mktemp msgc mtree pax 
pwd-mkdb rpcgen stat sunlabel texinfo tsort uudecode yacc zic 

The majority of the host tools are installed with an “nb” prefix, to differentiate them from similarly 
named commands on the host. The exceptions are the GNU toolchain programs, which already have a 
name such as i386-netbsdelf-gcc. 

METALOG support 

Traditionally, install is run as root to install paths into the appropriate location under SDESTDIR (which 
defaulted to with the appropriate ownership and permissions. 

This prevents non-root users from building a full distribution, as many files need specific permissions, 
such as setting set-user-ID root on /usr/bin/su. 

To solve this issue, we enhanced the specification file for the existing mtree tool to support a full path 
name (versus a context-sensitive relative path name), and referred to the result as a “metalog” entry. An 
example entry is: 

./usr/bin/su type=file mode=04555 uname=root gname=wheel time=1057493599.102665 

For a given build, a METALOG file is created, with a “metalog” line for each installed path name. The 
METALOG file is manipulated and parsed by various tools as necessary throughout the full build process. 

install was modified to optionally install the paths as the current user and without any special per¬ 
missions, and instead log the requested permissions to the METALOG. The “.mk” files in src/share/mk 
and a small number of special case Makefiles were all that needed to be modified to take advantage of this 
support in install. 

pax was modified to support parsing a METALOG for the list of paths to add to an archive, and even 
add “fake” entries for devices which may not have been created in SDESTDIR. This is used to build .tar.gz 
files which contain the correct ownership and permissions from a METALOG and SDESTDIR populated 
by a build by an unprivileged user. The scripts that create the “installation sets” were enhanced to parse 
the META LOG and invoke pax appropriately. 

makefs 

Various platforms use distribution media which require a FFS file system to boot from. Previously, NetBSD 
built these using a “loopback vnode disk driver” ( vnd ), which is not available on many other systems, and 
requires root privileges to mount and write to in any case. 

makefs was added to create a file system image from a directory tree and optionally a METALOG. It 
is conceptually similar to mkisofs , a GPL-ed application which creates ISO-9660 file system images. 

With makefs, an unprivileged user can create a FFS file system, complete with device nodes (with the 
latter being specified in a METALOG). 

makefs has been written in a manner that easily supports the addition of different file system types. It 
currently only supports creating FFS file systems, in either little or big endian (since NetBSD’s FFS code 
supports opposite endian FFS file systems, c.f. the “FFS_EI” kernel option, and support in userland tools 
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such as newfs and fsck-ffs), and ISO-9660 file systems. Support for other file systems such as ext2fs, and 
FAT has been considered, but is not a high priority at this time. 

The implementation of the FFS back-end re-uses a reasonable amount of the existing source code in 
the current NetBSD kernel implementation of FFS (in src/sys/ufs/JJs), but for simplicity, functions such 
as the block allocation code were re-implemented in a simpler manner. Various assumptions were made as 
part of this process, including that block reallocation would not be necessary, since the size of all files and 
directories (as files) is known at file system creation time. 

While FFS was originally implemented as a user process before its integration into the 4.2BSD kernel, 
after two decades of kernel hacking it is heavily tied to the buffer cache and other kernel sub-systems, 
which makes it more difficult to use in a stand-alone program. 


installboot 

Most platforms need boot blocks on their distribution media, and these are installed with installboot. 
Previously, each platform had its own version of installboot in /usr/mdec/installboot, which was compiled 
as part of, and heavily dependent upon, the kernel sources for that platform. They also required root 
privileges and generally required kernel support for specific disk-label ioctl()’s and only worked on actual 
disk devices. 

/usr/sbin/installboot is a replacement for the machine-dependent versions of installboot. It can function 
on file system images, and doesn’t need root privileges or kernel support for specific ioctlQ’s to do so. The 
design of the boot blocks between the various platforms has been standardized as well, even if the actual 
implementation is different due to obvious differences in platform hardware. 

All platforms that shipped with binary releases for NetBSD 1.6 (except NetBSD/i386) were converted 
to this new infrastructure. NetBSD/i386 was a special case due to the baroqueness of the implementation 
of installboot for that platform, but as the “cross build” host for the NetBSD/i386 release was a dual 
processor i386 box, it could run the tool “natively”. This was resolved in NetBSD 2.0. 

On a related note, it is possible to make CD-ROMs that boot NetBSD on multiple platforms. For 
example, NetBSD/i386, NetBSD/sparc64, and NetBSD/macppc can boot off the same disk, and there’s 
ample room for other platforms. NetBSD 1.6, with the 39 platforms that shipped with a binary release 
and associated source, fit on 4 CD-ROMs and booted on 9 of them. 

postinstall 

postinstall is a script that checks for and/or fixes configuration changes that have occurred as NetBSD has 
evolved. 

postinstall was added to the build system to detect, and in most cases, automatically fix, changes to 
configuration that must be performed due to software changes. 

The tests that postinstall supports axe: 
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defaults 

/etc/defaults is up to date 

gid 

/etc/group contains required groups 

hosts 

/etc/hosts is up to date 

makedev 

/dev/MAKEDEV is up to date 

mtree 

/etc/mtree is up to date 

named 

named configuration is up to date 

pam 

/etc/pam.d is up to date 

periodic 

/etc/{daily,weekly,monthly,security} is up to date 

postfix 

/etc/postfix is up to date 

rc 

/etc/rc* and /etc/rc.d are up to date 

sendmail 

sendmail configuration is up to date 

ssh 

ssh and sshd configuration update 

wscons 

wscons configuration file update 

xll 

Xll configuration is up to date 

uid 

/etc/passwd contains required users 

obsolete 

obsolete file sets 


Table 5: postinstall tests 


src/xll 

The build.sh framework in NetBSD 1.6 did not support cross-building “xsrc” (NetBSD’s copy of the XFree86 
4.x version of X11R6). This required the Xll sets to be built manually on a native system. 

The src/xll framework was developed to allow the Xll source to be cross-built using build.sh in the 
same manner as the rest of the operating system. 

src/xll comprises a hierarchy of “reach-over” Makefiles that use the src/share/mk framework. The 
reach-over Makefiles were developed by hand - the native X11R6 imake framework has too many internal 
inconsistencies to allow easy automated generation of the reach-over Makefiles. 

We briefly considered using the cross-compile support available in the XFree86 4.3 imake framework, 
but that did not sufficiently address all of our cross-build requirements, especially the removal of the need 
for root privileges. 


Future Work 

pkgsrc 

“pkgsrc” (the NetBSD packages collection) is not cross buildable. A smaller number of particular, probably 
smaller packages would probably fairly easy to get cross buildable, but the vast majority would each require 
significant effort. 

There have been at least two suggestions to simplifying the solution to this problem: 

1. Krister Walfridsson has detailed building the packages natively in an emulator [8], using optimizations 
such as only emulating user-mode, and capturing system calls and running those natively (after 
manipulating the arguments). 

An enhancement to that is to detect if an emulated program is gcc (for example), and invoking the 
host’s cross-compiler natively for that case. 

The initial progress looks very promising, with a arm emulator compiling six times faster than the 
native platform. 

2. Use a tool such as distcc [9] to distribute the compilation of C or C++ code to (faster) remote systems, 
even if those systems are different to the current system, as long as an appropriate cross-compiler is 
available. This would still require the use of the native system for part of the build process. 


Conclusion 

build.sh has been an extremely useful solution to a variety of problems. It’s now much simpler to build 
NetBSD releases from systems running earlier NetBSD releases, and even build on other systems such as 
Darwin (Mac OS X), FreeBSD, Linux, and Solaris. 
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Generally, the support issues in NetBSD using build.sh have been less than for previous releases, es¬ 
pecially considering the number of platforms now supported. Previously, it was extremely important to 
upgrade various in-tree tools, includes, and libraries in a specific order (that often changed) before com¬ 
pleting the rest of the build. Now, a full build can be made without impacting the running system, and 
then an upgrade easily performed once a successful build is available. 

The authors regularly use build.sh to cross-build entire releases on our (faster) NetBSD/i386 systems 
for platforms such as NetBSD/alpha, NetBSD/i386, NetBSD/macppc, NetBSD/pmax, NetBSD/shark, 
NetBSD/sparc, NetBSD/sparc64, and NetBSD/vax, as an unprivileged user using read-only source. 
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Hurd is where I hide 


Andrew Chalmers 


Imajica’s thoughts on hacking and sanity at 3:45 am a couple of hours before a print deadline. 

With apologies to Dave Graney & the Coral snakes. 

Hacking on the edge is hard because programming culture is forever changing, every aspect seems to 
move in a quickly flowing synthetic evolution that contains our parallelism of the real world and the biology 
within. Coding practice and methods change almost weekly and standards are fast becoming a dream 
someone once had back in the sixties. This is the reality if you follow the bleeding edge, everyday there is 
something new and shiny around the corner. To just keep up you need to be compulsive and constantly 
aware, to be creative and productive on the edge you really need to be obsessed in your particular field. 

I guess you have to understand that I am one of these freaks that enjoys solving problems by writing 
code, I don’t shy away from that, it’s who I am now as much as where I have been, so I am a proud 
computer geek and thus compelled to hack everything, at least to the point where I have ripped it apart 
and have attempted to put it back together again. I stress attempted. 

So keeping my grip on sanity and the requisite social skills becomes very very important, as it’s hard 
telling your significant other that you can’t talk right now because you have a head full of last night’s 
Laguerre function implementation. It’s also hard for non hackers to understand how we get so engrossed 
in the minutia of problem solving, and yeah sometimes this behaviour really is not at all healthy. 

I have found that to stay reasonably sane I need an intermediate pressure valve, a simple hacking 
project to keep my brain from atrophying, yet isn’t quite as intense as say, attempting to find predictable 
boundary patterns in certain crypto hash’s ... cough, ahem. For me, for the last couple of years that valve 
been hacking on my Hurd installs. 

After years of writing some pretty uninteresting code for various corporate interests I can honestly tell 
you that the only thing that has kept me interested in programming at all, are fringe projects. It’s a 
simple joy I share with thousands of hackers, to find out why something is broken and having the request 
resources and tools to fix it. This is something we defiantly take for granted now, but it was not always 
so. We collectively owe a great debt to the people that had to fight for free code some twenty years ago, 
and to those that still fight on our behalf today. By hacking Hurd every now and then you get to repay a 
small chunk of the obligation to contribute be it code documentation or testing, and it feels wonderful. It 
is for this very reason that programming enthusiasts will always share code, even if its just “I broke this, 
but this is how I fixed it” type code. 

As experienced hackers we know the utter frustration of being denied an answer, no matter what we 
try or the skills we bring to bare, simply because of selfish and narrow interests. This is simply not an 
issue with GNU Hurd. It’s easy to hack, it’s completely available and accessible to anyone that wants to 
learn the system, and there’s plenty of help available now that the project has started to ramp up once 
again. 

Why has this happened now? Personally I put it down to the fact that most other OS projects have now 
reached hacker niche saturation point, and have completely polarised under the leadership of one person. 
This is a problem in many respects for anyone that just wants to contribute some cool code. On just about 
any project you face the increasing possibility that you will never see your clever hack going to the main 
branch of your favourite project, simply because the politics of your peers keeps getting in the way. 

Don’t get me wrong - sometimes this attitude is completely justified and there are examples where this 
approach works well, but this reasoning can result in complete disaster for those who don’t quite realise 
what they have got themselves into. I fear we are losing good hackers forever because of this. Again this 
is not an issue with GNU Hurd, the projects expectation’s are clearly spelt out when you read the licence, 
you are welcome to contribute code if you wish, so long as you distribute by the rules set out, once again, 
in the licence. The whole point of the project is to remove arbitrary restrictions from users and make their 
computational existence easier. This goes double for the hackers themselves. 
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On the technical nature of the project. 

For those who come in late, GNU Hurd is built on, and complements with extra functionality, a kernel 
architecture that differs from things you are probably familiar with such as *BSD or Linux. In GNU Hurd 
the role of the kernel is to simply allocate resources to processes, via simple memory management some 
task and context switching and really not much else. Everything else including modules and processes are 
run as an individual system service that can be controlled and even swapped out (for instance when a 
process breaks) during run time. 

This method of execution is called a micro kernel architecture ... what this really means is that you 
don’t have a massive file to load as root at boot time and you don’t have to load modules for your hardware 
or system process as root either. There are clear advantages to this approach, but every time I look at a 
paper on Hurd or join a discussion I encounter a fight on the benefits and disadvantages of micro versus 
macro kernels, I am guessing everyone else is as bored with this as I am so I will avoid it by simply sticking 
to my experience with the GNU Hurd and try and explain just why I find it so attractive as a project. 
Hurd provides an (almost) transparent code compatibility layer, in that if you stick to the standard headers 
when writing an application it will just work, you don’t have to write endless device specific code ... this 
can makes the entire process of writing fast code really painless. Simply Hurd is such a moving target, 
there is always something new to explore, and because its so hackable its really accessible to anyone that 
can invest the time to learn the basics. I think it’s this aspect more than anything else that draws me in. 
How hackable? Right now, there are at least three different kernels for Hurd! 

GNU Mach 

Mach is the original GNU system kernel, it nominally requires an additional interface generator called MIG 
to compile programs for Hurd that use the GNU C library and Mach interfaces as remote procedure calls 
(RPC’s). This overhead can be ... frustrating but it does make the process of using, and more importantly 
controlling, applications under Hurd easier for the end user. Mach has been in use for a long time, and 
there is a LOT of emotional energy invested in it, principally because it was one of the first real victories 
for the GNU movement in regards to getting third parties to release source code under the GPL. However 
it’s important to note that as the device drivers for block and network devices are taken from some of the 
Linux 2.0 source tree, some modern hardware may be somewhat limited. 

OSKit-Mach (GNU Mach 2) 

This is where the OSKit library should come into play. This new version of Mach has been based, as the 
title suggests on the OSKit library and these device drivers are derived from both Linux 2.2 & 2.4. The 
problem we have at the moment is that most of the development on OSKit-Mach or GNU Mach 2 has 
stopped in favour of developing the Hurd flavour of the micro kernel system called L4Ka. 


L4 (Pistachio) 

This is the alpha stage kernel, but work on it is developing at a furious pace and there is a massive effort 
under way right now to port POSIX threading to the L4 kernel system. It is an impressive high performance 
kernel that runs on many architectures. It has a very bright and shiny future. 


On the future, should our sanity hold. 

For me GNU Hurd represents the unending possibilities of hacker imagination. The project will hopefully 
constantly require an understanding of programming techniques that span over thirty years, currently the 
code base is a mixture of every programming style you can imagine, many eyes do indeed prove shallow 
bugs ... right up to the point where you realises that everyone is using a process and a methodology that 
is simply so outdated that the bulk what what you are trying to achieve is simply trying to get crufty code 
to do things it was never designed for. Which is of course the point of why I am writing this, to engage 
your enthusiasm and to show you that there are large projects out there that need people like us now. 

Rant time, Life on the frontier has always been hard, it’s supposed to be - that’s why it’s called the 
frontier and not the happy place with all the tea and biscuits you can scoff. Seriously, GNU Hurd is not 
that strange and difficult a beast to fully grok ... once you get into it... I find it so frustrating that people 
give up trying to understand or just constantly complain about the way Glibc looks and acts and yet do 
nothing to help fix it. Yes, anyone that has ever attempted to install Hurd from scratch will know that 
its not the most intuitive of processes, there is so much you are expected to understand from the very 
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beginning, it’s here that most people simply give up and refuse to begin the process of learning anything 
new. But that’s the nature of challenge, yes it’s a different type of kernel with a different way of looking at 
process and runtime but then that’s why you are here right? I honestly think that the failure of some of my 
peers to take on new things (or help fix old things) is defiantly symptomatic of one of the biggest problems 
we all face as hackers, I fear we have become regimented to the extent that we are loosing the ability to use 
group inductive reasoning in problem solving. “Let the project leader deal with it” as a prevailing attitude 
in any project cannot be healthy and as a result I think for a lot of us the joy of hacking is fading. It seems 
that anything new or not extensively tested seems to frighten everyone at the moment, anything you have 
to think about or read about seems to be out of reach all of a sudden. Where’s the spirit of adventure? I 
am crying out to you, guys come on get back into it ... why did you get into hacking in the first place? 

You will probably never get the chance to be as free with your code as you would like in the commercial 
world, but when you have access to the complete source, the time and the ability to read code you have 
every opportunity to excel as a thinking human being, and thus the opportunity to stay somewhat sane. 
The philosophy behind this last statement may sound lofty and perhaps naive but without wanting to 
constantly move ahead on new ideas and techniques we will suffer the same fate as the commercial world, 
focusing on only deliverables and time frames and even possibly profit margins, (eeeewww) You owe it to 
yourself to be better than that. 

Hacking on Hurd helps keeps me sane, there are always major problems to deal with, but there is 
always someone that can help you out with an answer or an idea. It’s a very fine balance. Hurd needs good 
hackers NOW, the code base is really chock full of cruft but as I have said the project has started ramping 
up again, and there are now three kernels to work on, and as other FOS projects continue to polarize the 
GNU Hurd will always welcome a good honest hack. It is and hopefully will always be the frontier. Go 
forth and hack, Qapla! 

ALC 2005 
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Abstract 

MCS (Multi-Category Security) is the latest development in SE Linux policy. It uses some of the features 
of MLS (Multi-Level Security) to provide extra protection. 

MLS is based on sensitivity levels and categories. In MCS there is only one sensitivity level so therefore 
levels do not matter. Categories are the only part of MLS that is used. MCS is currently implemented on 
both the “strict” and “targeted” policies for SE Linux. 

This paper describes the basic concepts of MLS, the design of MCS, and some of the implementation 
details. 


MLS levels 

MLS[1] is a MAC (Mandatory Access Control) system. This means that the access controls are enforced 
by the system and the user does not have discretion to avoid using them. DAC (Discretionary Access 
Control) is a system whereby each process can determine the access to be granted to each object it creates, 
for example a process can create a file in /tmp and give it mode 0777 to grant full access to all other users. 
Most mass-market operating systems implement DAC at best and have no support for MAC. 

The primary characteristic of MLS is that it has multiple security levels. These are often named Top 
Secret, Secret, Classified, and Unclassified. There is no technical requirement that there be four 
levels (there could be more or fewer), or that those names be used. In a MLS system the primary aim is 
to prevent “read up” or “write down”. “Read up” means reading data that is classified at a level higher 
than the process that is reading it, for example a process which has a clearance level of Secret can not 
read data from a file classified at the level of Top Secret. “Write down” means writing data into a level 
lower than the process that is writing it, for example a process which has a clearance of Secret writing 
to a file classified as Unclassified. Preventing “read up” and “write down” means that both intentional 
release of secret data to processes/people that lack appropriate clearance and accidental release via trojan 
horse programs is prevented. 

It is permitted to “write up” and “read down”. In practice this means that a document can be written at 
a Top Secret classification which is based on data from Secret, Classified, and Unclassified categories. 
Also a process running at Unclassified level could write to a file classified as Top Secret. 

There is another issue of integrity which is addressed in SE Linux by using the domain-type model. 
Also a MLS system may rely on DAC to prevent unauthorised programs at a low clearance level from 
writing to highly classified files. MLS is generally not used for integrity of data. Trusted Irix contains a 
MLS integrity implementation^], but this has not been implemented in SE Linux and is very complex so 
I won’t describe it. 


MLS Categories 

Levels are not adequate to fully describe the security needs of military agencies or the computer systems 
that they use. It is common that people will not be permitted to read data that is at a classification level 
that they have clearance for but is in a different area (project, organization, etc). To implement this the 
MLS model includes a feature known as Categories. Every process in the MLS model has a clearance 
that includes zero or more categories. Each file that may be accessed will have a classification which also 
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includes zero or more categories. If the set of categories for which the process is cleared is not a super-set 
of the categories with which the file is classified then the file can not be read. 

In a commercial environment you might have categories for each NDA agreement that you sign with 
another company, for each secret research and development project, and for information that can’t be 
released due to insider trading laws. 


SE Linux Implementation of MLS 

SE Linux provides a MAC system that is a second layer of defense, Unix permissions are the first line of 
defense. So you may have multiple users who have the same SE Linux security context who keep their data 
secret from each other through Unix permissions. 

The primary feature of SE Linux is the domain-type model. In this model every process (subject) 
has a domain associated with it and every object that a process may access has a type associated with 
it. At the core of SE Linux is a database which describes for every combination of domain and type the 
access that is to be granted at a fine granularity [4], For example file access is divided into create ioctl 
read getattr lock write setattr append link unlink rename. 

Until recently the vast majority of SE Linux users did not use the MLS features. The most popular 
implementation of SE Linux has been in the Red Hat distributions, Fedora Core and Red Hat En¬ 
terprise Linux. In Fedora we have two policies, strict and targeted. The strict policy aims to grant 
minimal privileges to each process while the targeted policy has a domain named unconfined_t that has 
no restrictions and runs all programs from login sessions in that domain [5] [6]. The targeted policy aims 
to reduce the cost (in terms of administration work) of using SE Linux as much as possible. 


The design of MCS 

MCS is an extension to both the strict and targeted policies which was mostly designed for the targeted 
policy. It aim is to allow categorising data without increasing the difficulty of system administration. The 
full MLS model requires some significant changes to typical Unix administration practices, the feature of 
preventing “read up” and “write down” is in stark contrast to the Unix tradition whereby highly privileged 
(root) processes can do everything that they want to less privileged processes and resources. 

To avoid the full cost of MLS it was decided that levels would not be used. The SE Linux design permits 
using a policy that has no reference to MLS (no levels or categories defined) which has been commonly 
used in the past. However there is no support for a policy without levels but only categories, so for MCS 
we just define a policy with only a single level. The level is named sO (for a MLS SE Linux policy the 
default configuration is to have sensitivity levels named sO si s2 s3 s4 s5 s6 s7 s8 s9). 

When labelling files and directories on disk each file system object has an XATTR named secu- 
rity.selinux that contains the security context for the object. If an object has a security context which 
does not match the policy which is in use then it is given the type unlabeled_t which prevents access to 
all processes other than those run by the system administrator. In the previous versions of the SE Linux 
kernel code if a file had a security context without the MLS components then it would get the type unla- 
belecLt which made an upgrade from a non-MLS system to MLS more difficult than necessary. A recent 
change in the kernel code assigns a default sensitivity level to such files. So when upgrading a machine to 
the MCS policy all files will have level sO and no categories which is exactly what we desire for an initial 
MCS installation. 


Integrating MCS into a distribution 

Supporting MCS in a distribution requires a lot more work than just adding it to the policy. It has to 
be possible to manage the labelling of files and processes in a manner that’s not overly difficult. The 
basic support for changing the security contexts of files and preserving the context when copying files and 
backing them up has been in Fedora since Fedora Core 2. One of the issues with MLS is that only certain 
combinations of categories may make sense. So we need to have a method of translating MLS contexts 
to a human readable form. In rawhide we currently use the file /etc/mcs. conf to store translations from 
MLS labels to human readable labels, below is an extract from the default file: 

# sO:cO=CompanyConfidential 

# sO:cl=PatientRecord 

# sO:c2=Unclassified 

# sO:c3=TopSecret 
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# sO:cl,c3=CompanyConfidentialRedHat 
sO= 

sO-sO:cO.cl27=SystemLow-SystemHigh 

If the comment characters are removed then this means that category cO maps to CompanyConfidential 
and the combination of categories cO and c3 maps to CompanyConfidentialRedHat. Will; the current 
implementation a combination of the categories cO and cl will not be translated, a translation is only 
applied if there is an exact match from the AILS context to an entry in the mcs.conf file. This mapping is 
used by programs such as Is to display the context of files when the -Z option is used to display SE Linux 


contexts: 




# Is -laZ 

drwx 

rjc 

rjc 

rj c:obj ect_r:staff_tmp_t:SystemHigh 

drwxrwxrwt 

root 

root 

system_u:object_r:tmp_t 

-rw-rw-r— 

# Is -la 

total 32 

rjc 

rjc 

rjc:object_r:staff_tmp_t foo 

drwx 

2 rjc 

rjc 

16384 Sep 28 17:05 . 

drwxrwxrwt 

15 root 

root 

4096 Sep 28 17:22 .. 

-rw-rw-r— 

1 rjc 

rjc 

0 Sep 28 17:05 foo 


In the above example you can see that the directory in question has the level sO and the categories cO 
to cl 27 inclusive. 

Below is an example of the output of the id command: 

# id 

uid=0(root) gid=0(root) 

groups=0(root),l(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) 
context=root:sysadm_r:sysadm_t:SystemLow-SystemHigh 

The above output shows that the clearance of the current process is s0-s0:c0.cl27. 


Further development of MCS/MLS 


The MCS policy not only provides the benefits stated previously but also facilitates further development 
of the MLS features of SE Linux. Prior to the release of MCS hardly anyone was using the MLS features 
which meant that numerous usability issues were not being addressed. The release of MCS means that 
many organizations which would not consider a full MLS implementation will now be using MLS features - 
and expecting them to work correctly! This of course means that software developers (people who work for 
the distributions of Linux, “upstream” free-software developers, and commercial application programmers) 
will be compelled to make their software work in an AILS environment. This addresses the greatest problem 
that has faced commercial use of MLS systems, the fact that almost no software was written specifically 
to support it and most of the software failed to work in some way when used on an MLS system. 

When the MCS policy is widely released (Fedora Core 5 and Red Hat Enterprise Linux 5) it will be 
quite easy to convert an FC5 or RHEL5 machine to the full MLS policy. NB The full MLS policy will not 
be covered by the standard Enterprise Linux support contract. 

The full MLS policy is designed to fulfill the requirements for certification under the Labeled Security 
Protection Profile (LSPP)[7] Certification is a long process, merely having MLS support is far from 
enough to get certification. 


Future areas of work 

Future ideas include SE Linux support in a database server (per-row security contexts), SE Linux support 
in a mail server (which is more suitable to MLS than the domain-type model), and labeled printing (where 
evcr > print job gets a header to indicate the classification of the document and the print server may decline 
to send some jobs to printers regarded as insecure). 

For more information see references [8] and [9]. 
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Abstract 

Network latency has a significant impact on TCP performance, as does the use of delayed acknowledgments 
and the choice of initial window size. This paper presents research undertaken to analyse the impact that 
these three parameters have on TCP performance, specifically when TCP is being used over geostationary 
satellite links. The relationship between each of these parameters has also been studied via simulation, 
with the findings detailed and discussed. As a result of these findings, we have proposed a number of 
possible solutions that allow for the impact of latency on TCP performance to be minimised. Furthermore, 
we have identified a number of areas that require further research, providing a basis for future work. 


1 Introduction 

The Transmission Control Protocol (TCP) [1] is a self-clocking protocol and relies on regular feedback 
in order to increase or decrease the amount of data that it injects into the network. If this feedback is 
delayed, the throughput achieved by TCP is significantly degraded. Feedback is delayed when a network 
exhibits a large Round Trip Time (RTT); a result of network latency. Furthermore, the implementation of 
delayed acknowledgments halves the amount of feedback generated by the receiver. Both of these factors 
negatively impact TCP performance as the growth of the congestion window ( cwnd ) used by the congestion 
control algorithms is slowed. The initial window size also plays a crucial role, due to the exponential window 
growth implemented by most TCP variants during startup. A number of other flow-on effects are discussed 
throughout this paper. 

The intention of this paper is to provide a basis for further research by analysing the impact that network 
latency, delayed acknowledgments and initial window size have on TCP performance. Of particularly 
interest is the impact that these three parameters have on TCP when it is used over geostationary satellite 
links, where the RTT exceeds 500ms. The relationship between these parameters is also investigated. 

Section 2 provides background information on network latency, TCP congestion control algorithm 
implementation, delayed acknowledgments, initial window size and packet loss. Section 3 details the 
design of the simulations used in order to analyse the impact of network latency, delayed acknowledgments 
and initial window size on TCP performance, with the results being analysed and discussed in section 4. 
Section 5 presents a number of possible solutions. Finally, possible further research is described in section 
6 and conclusions are drawn. 
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2 Background 

2.1 Network Latency 

All communications infrastructure exhibits latency resulting primarily from the propagation delay of the 
physical transmission media, coupled with equipment induced latency. The propagation delay component 
is dependant on the type of transmission media in use, with the delay being a combination of the media 
propagation velocity, the distance that the data has to travel and the speed at which the data is being 
sent. This delay can range from nanoseconds for a short distance optical fibre, through to hundreds of 
milliseconds for a geostationary satellite link. Additionally, networking equipment such as switches, bridges 
and routers add to the latency of a network as data is queued and dequeued, buffer space is consumed and 
routing decisions are computed. In many cases, little can be done to reduce network latency, as the laws 
of physics will dictate the propagation delay for a particular transmission media. Observed RTTs include 
30ms for an ADSL connection, 130ms for an analogue modem connection and 560ms for a geostationary 
satellite link. 

2.2 TCP Congestion Control 

When a TCP session is established, the sender has no information regarding the network that lies between 
itself and the receiver. As a result, it needs a way to probe the network for capacity allowing it to increase 
the rate of transmission, without flooding or overloading the network. This is achieved by the congestion 
control algorithms that form part of the TCP implementation. The exact algorithms used differ between 
variants and are detailed further in the following sections. 


2.2.1 TCP Tahoe, Reno and New Reno 

Most of the TCP variants use the slow-start and congestion-avoidance algorithms designed by Jacobson 
during the late 1980’s [2]. During the slow-start phase, TCP increases its congestion window ( cwnd ) 
exponentially, effectively increasing the window size by one segment for each segment that is successfully 
delivered and acknowledged. At any point in time, the maximum amount of unacknowledged traffic that 
may be in transit across the network is the lesser of cwnd and receiver’s advertised window (r-iwrad). Slow- 
start is terminated if a segment is dropped by the network, the congestion window reaches the slow-start 
threshold ( ssthresh , which is initialised to 65536 bytes when the connection starts) or if the rwnd size is 
reached. If slow-start was terminated due to the loss of a packet, ssthresh is set to half of the current 
value of cwnd , cwnd is reinitialised to the initial window size and slow-start is restarted. If slow-start 
was terminated due to cwnd reaching the ssthresh or rwnd value, the congestion-avoidance phase begins. 
During congestion-avoidance, the congestion window is increased by cv } nd for each acknowledged segment, 
which equates to an increase of one segment each time the entire window is successfully transmitted and 
acknowledged. If a packet is lost during the congestion-avoidance phase, the slow-start phase will be 
resumed after setting ssthresh to half of cwnd and reinitialising cwnd to the initial window size. This 
follows the additive increase, multiplicative decrease model, providing a stable network that will not suffer 
from congestion collapse. 

Two additional algorithms, fast-retransmit and fast-recovery, are implemented in TCP Reno, allowing 
for the recovery of a single lost segment within a window; without causing a major impact on throughput. 
The initial versions of the fast-retransmit and fast-recovery algorithms are detailed in RFC2001 [3] and 
are further refined in RFC2581 [4], TCP New Reno implements a modified version of these algorithms, 
which is capable of recovering from multiple lost segments within a single window. The New Reno version 
of these algorithms is detailed in RFC3782 [5]. 

2.2.2 TCP SACK 

The use of Selective Acknowledgments (SACK) [6] provides increased feedback to the sender in regard to 
segments that have been received and queued by the receiver, but are not yet acknowledged due to one 
or more segments that are missing from the window. This information allows the sender to selectively 
retransmit the packets that have not been received, reducing the number of costly timeouts that occur. 
This is especially critical where packets have been lost due to corruption, as it allows for these packets to 
be simply retransmitted without retransmitting packets that have already been successfully received but 
not yet fully acknowledged. The base congestion control algorithms used for a TCP SACK implementation 
are the same as the Reno congestion control algorithms, with minor modifications to allow for the use of 
the SACK information during retransmissions. 
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2.2.3 TCP Vegas 

Unlike most TCP variants, TCP Vegas [7] does not rely on lost packets in order to gauge network capacity, 
instead using RTT measurements to determine the available network capacity. The congestion control 
algorithms within TCP Vegas calculate the expected throughput rate and the actual throughput rate once 
per RTT. The difference between the actual and expected rates is then calculated and cwnd is increased or 
decreased accordingly. During slow-start cwnd is increased by one segment for every two RTTs, differing 
from one segment per acknowledgment, as used in traditional TCP. When in the congestion-avoidance phase 
cwnd will be increased by decreased by one segment or left unchanged, once per RTT. As shown by 

a number of researchers [7, 8, 9], this process results in congestion control algorithms that achieve better 
throughput and transfer more data for the number of packets transmitted across the network, achieving 
higher goodput. TCP Vegas is also more resilient to error prone links and will retransmit packets that 
have been lost due to corruption far sooner than other variants. For these reasons we have included TCP 
Vegas in our analysis. 

2.3 Delayed Acknowledgments 

Internet hosts should implement delayed acknowledgments as detailed in RFC1122 [10] and RFC2581 [4]; 
that is one acknowledgement should be sent for every two packets of data received, without delaying an 
acknowledgment for more than 500ms [10]. Whilst this reduces the amount of traffic on the return link for 
a TCP connection, it also reduces the feedback provided to the TCP sender by the receiver. The traditional 
TCP congestion control algorithms rely on this information in order to determine the available capacity of 
the network. Delayed acknowledgments slow the feedback to the sender, which can significantly increase 
the time spent in the slow-start phase. 

On an error prone link acknowledgments can be easily lost during transmission, further reducing the 
feedback that the TCP sender has from the network. A lost acknowledgment will cause the sender to 
retransmit the original packet, unless it is acknowledged by a second acknowledgment with a higher sequence 
number. If an acknowledgment is lost and a later acknowledgment is delayed, the chance of a coarse timeout 
occurring is greatly increased. Additionally, when the congestion window has a size of two segments during 
the slow-start phase (either as a result of using an initial window size of two segments or after one RTT, if 
an initial window size of one segment is used), loss of the acknowledgment will result in a coarse timeout, 
effectively restarting the slow-start phase after setting ssthresh to a very low value. 

2.4 Initial Window Size 

Due to the exponential growth implemented within the slow-start algorithm used by most TCP variants, 
the initial window size can significantly impact congestion window growth, particularly for links that exhibit 
a large RTT. Prior to RFC3390 [11] being released in October 2002, Internet hosts could use an initial 
window size of 1 or 2 segments. RFC3390 allows Internet hosts to use an initial window size of 2, 3 or 4 
segments, with an upper limit of 4380 bytes. With a larger initial window size the duration of slow-start 
is decreased by one RTT for two segments and by two RTT for four segments, when compared to an 
initial window size of one segment. This is of particular importance for networks that utilise geostationary 
satellite links, where the RTT exceeds 500ms. 

Furthermore, if delayed acknowledgments are implemented by the receiver an initial window size of one 
segment will cause additional startup delays, due to the delayed acknowledgment maximum time having 
to be reached before the first acknowledgment is returned (this is often up to 200ms [11], although it may 
be as large as 500ms [10]). 

2.5 Packet Loss 

Packets are typically lost within a network for one of two reasons; congestion or corruption. When a 
network is experiencing congestion, buffers within network devices will reach capacity, resulting in packets 
being dropped. The standard TCP congestion control algorithms rely on the loss of packets to identify 
congestion within the network and as a result of packet loss, the transmission rate will be reduced. 

When a packet is lost due to error, TCP has no way to identify that it was not lost due to congestion 
and the congestion control algorithms will reduce the transmission rate, rather than retransmitting the lost 
packet. This behaviour causes a significant decrease in throughput, particularly when TCP is used over a 
network link that exhibits a high Bit Error Rate (BER). Wireless and satellite links are two examples, both 
typically exhibiting high error rates due to loss of signal strength, channel fading, noise and interference. 
It is interesting to note that the Jacobson congestion control algorithms assume that packets lost due to 
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Figure 1: Simulated Network 


corruption will be “much less than 1%” [3], a figure which is practical for wired networks, but impractical 
for wireless ones. 


3 Simulation Design 

A number of simulations were designed and executed using Network Simulator 2 (ns2) [12], in order to 
analyse the impact of latency on TCP. These simulations included evaluating a number of TCP variants at 
various network latencies, simulating throughput achieved for different initial window sizes and analysing 
the impact of delayed acknowledgments on throughput. The design of each simulation is fully detailed in 
the following sections. 

3.1 Latency 

In order to analyse the impact of latency on each of the main TCP variants, a simulation was designed 
that emulates a 30 second FTP file transfer between two hosts (A and B), over one hop (R), as shown in 
figure 1. Both links were simulated as being error-free in order to avoid the impact of lost packets and 
error recovery. The simulation used an initial window size of two segments, a Maximum Segment Size 
(MSS) of 1000 bytes and delayed acknowledgments were implemented at the receiver. This simulation was 
executed using each of the main TCP variants (Tahoe, Reno, New Reno, SACK and Vegas), with the RTT 
being varied from 5ms to 605ms, in 10ms increments. The data generated by each of the 300 runs was 
then analysed, with the highest sequence number acknowledged being used as an indication of achieved 
throughput. Additionally, graphs were produced providing a visual representation of the results. 

3.2 Delayed Acknowledgments 

The latency simulation was repeated with the receiver acknowledging each and every packet as soon as it 
was received, allowing for the impact of delayed acknowledgments on TCP throughput to be measured. 
Once again, the data from the 300 runs was analysed, with the highest sequence numbers being identified. 
The achieved throughput was then compared against that recorded in the previous simulation, allowing 
for the difference in throughput to be calculated. As for the previous simulation, the results have also 
been graphed providing a visual comparison between the throughput achieved, with and without the use 
of delayed acknowledgments. 

3.3 Initial Window Size 

As previously discussed, the initial window size implemented by the sender significantly impacts TCP 
throughput, particularly as the RTT increases. In order to evaluate the impact caused by the choice of 
initial window size, the same base simulation was executed using TCP SACK and TCP Vegas. The Tahoe, 
Reno, New Reno and SACK variants all use the Jacobson congestion control algorithms, varying only in 
their mechanisms for the recovery of lost packets. Since the link was simulated as being error-free, only 
one of these variants was required. 

For each of the 60 different RTTs simulated, an initial window size of 1, 2, 3 and 4 segments was used 
providing a total of 240 runs per variant. All simulations implemented delayed acknowledgments at the re¬ 
ceiver. The data generated by each run was then analysed to identify the maximum acknowledged sequence 
number. The throughput data was then three-dimensionally graphed providing a visual representation of 
achieved throughput. 


4 Results 

In this section the results produced by the previously detailed simulations are presented, in both tabular 
and graphical forms. These results are analysed and discussed, with the aim of providing direction for 
future research. 
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Figure 2: The impact of latency on TCP throughput 
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Table 1: Throughput difference between delayed & non-delayed acknowledgments 


4.1 Latency 

The results from the simulation detailed in section 3.1 are shown in figure 2. As expected Tahoe, Reno, 
New Reno and SACK share the same throughput graph, due to the link being simulated as error-free. 
Effectively the only differences between each of these variants relates to the error recovery mechanisms 
implemented, as outlined in section 2.2. As the RTT increases the throughput decreases in a near linear 
manner, due to the increased duration of the slow-start and congestion-avoidance algorithms. A decrease 
of over 1500 sequence numbers is noted between a network with an RTT of 10ms versus one with an RTT 
of 600ms. 

TCP Vegas performs completely differently and very much unpredictably. At around 50ms the through¬ 
put decays in an exponential fashion, only to spike around 140ms and again at 200ms, 310ms, 500ms and 
540ms. As detailed in section 2.2.3 the TCP Vegas congestion control algorithms are based on RTT 
measurements. As the RTT increases, Vegas’ ability to determine available network capacity appears to 
decrease, which is further impacted by the use of delayed acknowledgments as discussed in the next section. 
Furthermore, TCP Vegas only adjusts the congestion window once per RTT, meaning that the adjustments 
will occur frequently for a short delay link, whereas they will occur infrequently for a long delay link. 

4.2 Delayed Acknowledgments 

As detailed in section 2.3, when delayed acknowledgments are implemented by the receiver, the feed¬ 
back frequency is reduced, increasing the the time spent in slow-start from R log 2 W [2] to approximately 
•Rlogj 5 W [13, 14], where R is the RTT in milliseconds and W is the window size in packets. This is veri¬ 
fied by the results shown in figure 3, where the TCP receiver implementing non-delayed acknowledgments 
results in increased throughput, particularly for networks with a large RTT. Once again Tahoe, Reno, 
New Reno and SACK share the same throughput graph due to the absence of errors. The difference in 
throughput for these variants, measured by sequence numbers, is provided in table 3. 

For a typical geostationary satellite link, the use of delayed acknowledgments is going to result in a 
throughput decrease that exceeds 7% under the conditions simulated, whereas a decrease of less than 0.8% 
will occur for a typical ADSL connection. Obviously these figures will vary depending on the duration 
of the TCP session, the traffic already utilising the link and the error rate exhibited. Nonetheless a 7% 
decrease on a link that is simulated as being error free should not be ignored. 

The throughput achieved by TCP Vegas is very similar to that noted in the previous section, however 
the use of non-delayed acknowledgments results in further strange behaviour. For networks with a RTT less 
than 200ms, the use of non-delayed acknowledgments increases the throughput achieved by Vegas. In fact, 
for links with an RTT less than 100ms TCP Vegas achieves throughput similar to the other TCP variants, 
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Figure 3: Delayed vs Non-delayed Acknowledgments 


'-RTT 

IWS 

50ms 

250ms 

550ms 

1 Segments 

7335 

6838 

5929 

2 Segments 

7373 

6926 

6092 

3 Segments 

7387 

6990 

6231 

4 Segments 

7399 

7030 

6291 

Gain 

64 

192 

362 


Table 2: Impact of Initial Window Size (IWS) on Throughput 


when delayed acknowledgments are implemented. However, as the RTT reaches 200ms the use of non- 
delayed acknowledgments results in Vegas achieving less throughput, even though the throughput decay is 
much smoother as the latency increases. As previously observed, several spikes occur in Vegas’ throughput 
as the latency is varied. With non-delayed acknowledgments a major spike is observed between 350ms 
and 370ms, with a gain of around 800 sequence numbers. It is envisaged that the RTT based congestion 
control algorithms could be improved to better handle the variance in RTT measurements caused by the 
use of delayed acknowledgments. 

4.3 Initial Window Size 

The impact of the TCP initial window size can be seen in figure 4, with the left axis representing the initial 
window size, the right axis representing the RTT of the network and the vertical axis representing achieved 
throughput. As expected, for the standard TCP congestion control algorithms as represented by TCP 
SACK, a larger initial window size results in increased throughput. As the network RTT increases, the 
throughput gained by using a larger initial window size increases, due to the congestion window opening 
more rapidly. As shown in table 2 the use of an initial window size of four segments will result in a gain 
of 362 sequence numbers when TCP is used over a typical geostationary satellite link, compared to an 
initial window size of one segment. The gain achieved by using an initial window size of four segments 
with a network having an RTT of 50ms, is less than one-fifth of that achieved for a network with an RTT 
of 550ms. 

The impact of initial window size on TCP Vegas is once again an anomaly, with an initial window size 
of two segments providing better performance than one or four segments. As observed in section 4.1 the 
throughput of TCP Vegas dips and spikes as the network latency increases. This holds true for each of the 
four initial window sizes simulated, with a significant decrease in throughput being noted when an initial 
window size of four segments is used over a network that has an RTT between 350ms and 420ms. This is 
more than likely due to the more conservative slow-start algorithm implemented within TCP Vegas, with 
the large initial window sizes possibly causing slow-start to terminate earlier than it should. An initial 
window size of one appears to incur a penalty due to the slower congestion window growth, whereas an 
initial window size of four appears to incur a penalty due to the early termination of slow-start. Further 
research into the relationship between TCP Vegas, latency, delayed acknowledgments and initial window 
size appears to be necessary in order to more clearly understand its behaviour. 
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(a) TCP SACK 


(b) TCP Vegas 


Figure 4: Impact of TCP Initial Window Size on Throughput 


5 Solutions 

A number of possible solutions exist aiming to minimise the impact of latency on TCP throughput. Each 
of these are outlined in the following sections. 

5.1 Non-Delayed Acknowledgments 

As shown in section 4.2, the use of delayed acknowledgments severely impacts TCP performance, especially 
when the network exhibits a large RTT. If an initial window size of one segment is used by the sender, in 
addition to delayed acknowledgments at the receiver, an additional period of 200ms-500ms will typically 
be added to the TCP startup overhead. Additionally, if TCP is being used over a link that exhibits a high 
BER, acknowledgments may be dropped due to corruption. This acknowledgment will be for two segments, 
the loss of which significantly increases the chance of a coarse timeout occurring. For these reasons TCP 
receivers located behind a geostationary satellite link would more than likely experience significant gains 
by disabling the use of delayed acknowledgments, in turn increasing feedback to the sender. 

One of the biggest arguments for the use of delayed acknowledgments is the reduction of traffic on 
the return link, which is often a smaller capacity than the inbound channel. However, given that a 
typical TCP acknowledgment will range from 40-bytes through to 80-bytes, using a MSS of 536 bytes and 
acknowledging every packet still allows for a link to be asymmetric with a ratio greater than 6:1. For 
example, a 1500/256kbps ADSL connection allows 400 80-byte acknowledgments to be sent per second on 
the return channel, meaning that a MSS size of 429-bytes will completely fill the inbound channel. 

Australia’s largest communications provider offers geostationary satellite access plans with speeds that 
range from 64kbps through to 512kbps, with a return channel of 128kbps or 256kbps. Alternatively, by 
using a different satellite platform inbound and outbound data rates of up to 2Mbps can be allocated 
according to customer specification. The most asymmetric connection available without a custom plan 
would be 512/128kbps, with a ratio of 4:1. This allows for 200 80-byte acknowledgments to be returned 
over the 128kbps link per second, resulting in a MSS size of 280-bytes being able to fill the inbound channel. 
If no IP or TCP options are used, resulting in an acknowledgment size of 40-bytes, an extremely small 
MSS of 120-bytes will be capable of completely using the inbound 512kbps connection. 

Using a more realistic example, a TCP acknowledgment that includes timestamps will be 52-bytes 
assuming no other options are used. Using the “default” MSS of 536-bytes the full payload will be 588- 
bytes per packet, after incurring 52-bytes for the TCP header, TCP options and IP header. Over a 512kbps 
link less than 109 588-byte packets can be received per second, resulting in less than 46kbps being required 
for the return path, if every packet is acknowledged immediately. 
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Obviously the above calculations do not take into account traffic travelling in the opposite direction; 
going out on the return channel and being acknowledged on the inbound channel. Depending on the 
network environment, this may or may not need to be taken into account. 

We propose that receivers who are connected to the Internet via a last-hop geostationary link should 
not implement delayed acknowledgments. This choice would need to be carefully considered prior to 
implementation, due to the increased usage of the return channel. It is envisaged that the impact on the 
sender will be minimal, as the sender will either be connected via adequate bandwidth (for example, a 
server in a data centre) or if connected via an asymmetric link, will have more inbound than outbound 
bandwidth available. Similar results would be achieved by enabling delayed acknowledgments only after 
slow-start [15] has terminated, reducing network traffic on the return link once the congestion-avoidance 
phase was reached. Alternatively, another method such as Limited Byte Counting (LBC) [15] could be 
employed by the sender, reducing the need for regular and rapid acknowledgments. 

5.2 Use of a Large Initial Window Size 

For all TCP variants that are based on the Jacobson congestion control algorithms, the use of a larger 
initial window size provides significant gains in throughput, specifically for networks with a large RTT. 
As a result, TCP senders should, where possible, use an initial window size of three or four segments as 
permitted by RFC3390. 

If delayed acknowledgments are implemented at the receiver, an initial window size of at least four seg¬ 
ments will also ensure that a minimum of two acknowledgments are returned immediately to the sender. 
This will achieve two things. Firstly, the congestion window will be opened faster due to the immediate 
feedback, reducing the duration of slow-start by several RTTs. Secondly, if one of the two acknowledg¬ 
ments gets dropped due to corruption the acknowledgment that is successfully received will trigger the 
transmission of at least two more segments, typically resulting in another acknowledgment. For these rea¬ 
sons we propose that all senders connected via a link that exhibits a high BER use an initial window size 
of four segments, reducing the MSS size to 1095-bytes if necessary, in order to come under the 4380-byte 
maximum. 

For TCP Vegas, the sender should use an initial window size of two segments in order to achieve 
maximum throughput, even though this will increase the slow-start duration and will be less resilient to 
the loss of acknowledgments. We believe that this is a possible deficiency in the TCP Vegas congestion 
control algorithms, a matter which may be resolved after further research. 


6 Further Research 

The behaviour of TCP Vegas is intriguing, particularly when delayed acknowledgments are implemented 
by the receiver, an initial window size greater than two segments is used or the network latency exceeds 
an RTT of 100ms. It is envisaged that further research into TCP Vegas’ congestion control algorithms will 
provide an in-depth understanding of this behaviour, allowing for modifications to be made that enhance 
performance and throughput, whilst maintaining the ability to rapidly recover from packet loss. 

The work detailed in the paper could be further extended by combining the impact of errors and 
packet loss into the simulations. In order to clearly understand the relationships between latency, delayed 
acknowledgments and initial window size, the links were simulated as being error-free, removing the impact 
of error recovery on throughput and performance. By adding error prone links to the simulations, the effect 
that these three parameters have on the recovery algorithms implemented by the TCP variants could be 
studied, providing further results and recommendations. 

A lot of research has been performed regarding the ability of TCP to quickly recover when packets are 
lost due to corruption. This research has resulted in the creation of the fast-recovery and fast-retransmit 
algorithms, selective acknowledgments and new variants such as TCP Vegas. However, little research 
appears to have been performed studying the impact of lost acknowledgments, particularly those that are 
lost during the initial stages of the slow-start phase or when the congestion window is small in size. Further 
research into this area may lead to improved algorithms that are more resilient when used over error prone 
links. 


7 Conclusion 

Network latency has a significant impact on the performance of TCP. In most situations little can be done 
to decrease the network RTT, as it is a result of the propagation delay of the communications media in use, 
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which in turn is bounded by the laws of physics. The Jacobson based congestion control algorithms are self¬ 
clocking and require feedback from the network. The existence of a large RTT reduces the feedback received 
from the network and slows the growth of TCP’s congestion window, reducing achieved throughput. 

Whilst network latency cannot typically be changed, a number of other parameters can be altered in 
order to increase performance. By not implementing delayed acknowledgments the amount of feedback 
to the sender is significantly increased, resulting in higher throughput and making TCP more resilient 
to packet loss on the return link. The increased number of acknowledgments allows TCP to open the 
congestion window more rapidly, and in the case of a geostationary satellite link the duration of slow-start 
can be decreased by several seconds. 

The use of a large initial window size also increases TCP performance, particularly for networks with 
large propagation delays. If delayed acknowledgments are implemented at the receiver an initial window 
size of at least four segments will result in two immediate acknowledgments, removing the delay caused by 
the receiver waiting for a second segment when only one segment is initially sent. Furthermore, the loss of 
one of these segments will not result in a coarse timeout, potentially increasing throughput. 

We have shown that users of geostationary satellite links will experience significant throughput gains 
by not implementing delayed acknowledgments and by using a large initial window size, when using TCP 
variants that implement Jacobson based congestion control algorithms. As previously detailed, the perfor¬ 
mance of TCP Vegas is far more unpredictable, especially as the network latency increases or if an initial 
window size of more than two segments is used. Further research is needed in order to fully understand the 
congestion control algorithms implemented by Vegas, allowing for modifications to be made that enhance 
achieved throughput when Vegas is used over long delay links. 
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Abstract 

The column My Home Network has been running in AUUGN since Volume 20 Number 2 (June 1999), 
well over 5 years, and has followed the changes in the computing field, particularly as it has affected a 
Small Office/Home Office (SOHO) configuration. In addition the column has followed lots of the changes 
in the Open Source community, particularly Linux systems. 

The column has also acted as a bit of a social experiment, in how a modern family really makes use of 
a computer network within their home. 

Finally, some views on what has been important and where things appear to be moving will be covered. 


Introduction 

The column My Home Network debuted in AUUGN in Volume 20 Number 2 (June 1999) it has been a 
running commentary on computer systems suitable for home and small office use. It is a chronicle of some 
of the changes that the computer industry has undergone and a look at what may happen in the future. 


Hardware 

Then 

While My Home Network has only been going for a bit over 5 years, my network is older than that, 
and so was in place at the start of columns. Quoting from my first article, what I had was: 

So, what do I have, for a start, 5 computers (in a house with 4 people and a dog!!!). They have 
gradually accumulated over the years, they have been upgraded and they have found various 
niches. Going through in decreasing use. The first is ‘cnc’, a Pentium 233MMX dual-booting 
between Linux 2.2.9 and Microsoft Windows98 and is used as my main workstation. Next 
is ‘jc’, a Macintosh PowerMac 5500/250, with a DOS Card running MacOS 8.5.1, Microsoft 
Windows95 and also LinuxPPC 2.2.9 (i.e. Linux for PowerPC). This is used for most of the 
children’s work, and fits in well with the systems they use at school. This is really a cool 
machine and means they can run just about anything that goes, Mac, Windows or Unix! In 
fact the split personality for this system means it has two names, ‘jc’ and ‘jcdos’. 

Next onto the older computers, ‘fpc’, a Macintosh 575, i.e. a 68040 system. This is used when 
other systems are busy or when it is more convenient as it is located in a bed room. It is useful 
as a backup for school projects, and has the same Internet access as any other system. In fact, 
its main use seems to be to play music CDs (a function it does well). I guess I could put Linux 
for an m68k on it, but the disk is small and I haven’t gotten around to it. 

Another older computer is ‘sac’, currently a 100MHz Pentium running Windows95, but cur¬ 
rently undergoing an upgrade. Eventually it will dual-boot Windows95 and Windows NT 
Workstation. 

Finally, the most interesting and most active system is ‘bits’, a small old, 66MHz Pentium 
(yes a really old system). It has been upgraded from my original 286, through to the current 
system. This is the most interesting and important system in the whole house. It is also running 
continuously, acts as a server for my home network and runs more applications and daemons 
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than the average server. It also runs Linux 2.2.8 (probably 2.2.9 or later by the time this is 
published). 

As well as computers there are two printers (one colour) which are usable by any computer on 
the network, a scanner which is currently connected to ‘cnc’ and at the moment only usable 
from Windows98 (and soon by Linux when support is available from the ParPort project) and 
a V.90 modem, shared across the network. And finally, at the lowest level, the whole lot is 
joined by a coax Ethernet network. 

So, to put it in a table what I had was: 


Host 

Hardware 

Operating System 

Function 

cnc 

Pentium 233MMX 

Linux 2.2.9/MS Win98 

Main Workstation 

jc 

PowerMac 5500/250 

MacOS 8.5.1/MS Win95 
/LinuxPPC 2.2.9 

School Work 

fpc 

Mac 575 (m68k) 

MacOS 8 

Minor uses 

sac 

Pentium 100 

MS Win95 

Test system 

bits 

Pentium 66 

Linux 2.2.8 

Server 


Table 1: Original Computer Hardware 

It is interesting that at that time all that was of interest was the CPU performance. There was no 
record of the RAM or hard disk size. I can say from memory that the RAM varied between 64MB (for 
bits) and 128MB, while the disk varied from 4GB up to maybe 10GB. 

Now 

Since that time there has been considerable progress in systems, but it is interesting that the number of 
systems I now have available has only increased by one, the addition of a laptop to the mix. 

A list of the current systems is: 


Host 

Hardware 

Operating System 

RAM 

(MB) 

Disk 

(GB) 

Function 

cnc 

2.5GHz Pentium4 

Linux 2.6.12/MS WinXP 

1024 

160 

Workstation 

age 

2.4GHz Pentium4 

Linux 2.6.13/MS WinXP 

512 

160 

Workstation 

sac 

533MHz Pentium3 

MS WinXP 

192 

10 

School 

age 

3200+ AMD64 

Linux 2.6.12 

1024 

20 

Test System 

bits 

1.3GHz Pentium Celeron 

Linux 2.6.13 

376 

120 

Server 

lap 

2.6GHz Pentium4 

Linux 2.6.12/MS WinXP 

512 

40 

Laptop 

jc 

PowerMac 5500/250 

MacOS 9/LinuxPPC 2.2.18 

64 

4 

Unused 

fpc 

Mac 575 (m68k) 

MacOS 8 

32 

2 

Unused 


Table 2: Current Computer Hardware 

There are a couple of notes that should go into here. Firstly, neither of the Mac’s are still in use. They 
are both available, but have not been switch on in some months. It certainly appears that Mac’s have lost 
mind share within the home environment. This is despite them having the ability to perform many of the 
functions that the WinXP systems can do. Similarly the DOS card and partition for jc effectively died off 
during an upgrade to Win98 and was never resurrected. Technically it could be run. 

The system sac is long overdue for an upgrade, and will soon get it. In fact it has recently been 
destroyed in a fire, but key components (i.e. the disk) were rescued, which will be used to reconstruct its 
descendant. 

Peripherals and Networking 

Just as important for a real use in any environment is the peripherals available. Over the intervening years 
there has been little change in them. There are still two printers, both of which are now colour, one even 
being the same as 5 years ago. As well, the scanner is still in use, and now also available under Linux. 

The other key component is networking, which previously used a V.90 modem and coax cable. This 
has change dramatically, with connection to a 512/64K ADSL connection and a Gigabit Ethernet (GbE) 
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switch on UTP forming the basis of the network. The modem still exists and is used for faxing, etc, but 
not as a key component. 

In addition to this for more difficult areas, wireless, in particular 802.1 lg, is in place. With a maximum 
speed of 54MBits/sec, while not as good as GbE, it is certainly comparable with Fast Ethernet (i.e. 
lOOMBits/sec) which most of the systems are actually supporting. This means that systems in parts of 
the house that are difficult to cable can still be part of the network. Even more importantly, it means that 
the laptop is truly mobile and can be used anywhere inside or outside. 


Software 

Software is a very different area to hardware, as it is something that has been continuously changing 
through all the years. However, there has been a variation in types of software that has been important. 

As can be seen from early columns, initially the software concentrated on basic network services and 
setting up the systems. In addition, there was considerable discussion on setting it up with both Linux as 
well as Microsoft Window systems, and even MacOS at times. But, as can be seen in the earlier tables, 
the initial install base consisted of Microsoft Windows 95 derived systems, with a few Linux and MacOS 
systems. 

The original columns discussed such products as diald and pppd, and in particular settings for them, 
gradually moving onto internal infrastructure, such as squid and ntp. 

More recently the software discussed has been more evenly split between general use software, such as 
gaim, basic infrastructure, such as virus scanning, and other system administration tools (after all, that is 
one reason for the existence of the system). More importantly, with the shift in distributions with operating 
systems to Linux, has come a change in the types of software. More and more the software being reviewed 
is general open source that is specific for Linux and other Unixes, and no longer suitable for WinXP. 

However, the increasing maturity of open source software (OSS) has meant that it is easier to use now 
than previously. However, this increasing maturity has also brought about an increase in the complexity 
of the packages being reviewed. Packages such as OpenOffice are now becoming a major part of the use of 
Linux, and it is far less likely to switch to a Microsoft OS. 

One other thing that can be noticed from the system lists is the development of various Operating 
Systems. Ignoring minor releases, it can be seen that there have been two major releases of Linux in that 
time (from Linux 2.2 to 2.4 and currently 2.6), while Microsoft had a single major release (from Win95 
series to WinXP), although the Microsoft minor release are sometimes much more extensive (e.g. Win98 
to WinME). 

Alternatively if you consider the release of Linux distribution, it has progressed from RedHat 6.1 through 
to RedHat 9 and then through the various Fedora Core releases (currently at FC4). This basically amounts 
to a new release every six months, which does give a considerable workload. 

One other change that has happened over the same time is massive improvement in maintenance and 
update tools and procedures for Linux systems. This is dependent on the specific Linux distribution, but 
for Red Hat derived systems has moved from just obtaining the RPM with mirror and manually sorting 
through the dependencies, to modern utilities like yum which automatically perform all these checks and 
download all the appropriate packages from across the Internet. 

Moore’s Law and Other Relationships 

Around October 2002, one of the columns looked at performance trends of various key components over 
the time of the systems. Most people are aware Moore’s Law which basically states that the number of 
transistors on a chip doubles every 18 months, and the corollary of this is that the performance of CPUs 
is also doubling in the same time. Further, as RAM is basically based on chip technology, RAM capacity, 
but not speed, is also doubling in the same period. 

A similar relationship exists for storage, called Kryder’s Law, which predicts that capacity doubles 
every 12 months. However, again, this does not relate to disk performance. 

And finally network bandwidth is doubling every 9 months. 

So, summarising all these items, it is interesting to see how closely the home computer network has 
been meeting these expectations over the last 6 years: 

As can be seen from this table, even within a home network, the exponential growth laws hold and 
give a reasonable estimate for the projected growth rate. Even more interestingly, the areas that currently 
are falling behind the curve, already have upgrade plans to bring them back into line. For example, a 
conversion to an AMD64 Dual Core 3800+ would put the CPU back on the curve. So extending the above 
table for planned installations for the near future would give: 
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Component 

Double 

Time 

Theoretical 

Increase 

Initial 

Current 

Actual 

Increase 

CPU Speed 

18mths 

16 

233MHz 

3.2GHz 

14 

RAM Capacity 

18mths 

16 

64MB 

1GB 

16 

RAM Speed 

N/A 


66MHz 

800MHz 

12 

Disk Capacity 

12mths 

64 

4GB 

160GB 

40 

Disk Speed 

N/A 


33MB/sec 

133MB/sec 

4 

Network (External) 

9mths 

256 

28Kbps 

512Kbps 

18 

Network (Internal) 

9mths 

256 

5Mbps 

lGbps 

200 


Table 3: Exponential Relationships 


Component 

Proposed Component 

Current 

Increase 

CPU Speed 

AMD64 Dual Core 3800+ 

3.8GHz * 2 

32 

Disk Capacity 

5 * 250GB Raid 5 

1TB 

256 

Network (External) 

ADSL2+ 

24Mbps 

857 


Table 4: Projected Exponential Relationships 


All of this shows that there is still considerable growth available in the home computer market. 


Social Perspectives 

While the technology aspects of a home network are interesting, like any computer system, it does have a 
purpose. In the case of a home network it is to support the requirements of the family. 

The interesting thing is what does the modern family do with the currently available computer power? 
While, admittedly, it is a small sample, but the relative order of importance seems to be: communications, 
work and entertainment. 

For children who have grown up around computers, it is seen as tool to keep in touch with their friends 
and relatives. It is used to form communities, but interestingly enough, these communities usually involve 
some form of physical interaction. The most common mechanism used for this is an Instant Messaging 
application, originally ICQ, and more recently Microsoft Messenger. The uses of OSS utilities such as gaim 
allow anyone to be involved in chatting. 

As a second string to communication is email, although again the usage pattern seems to vary with 
age. 

The second major application, which applies to the whole family, is the use of the system for work, 
either school work or paid employment. However, again, there is a big difference seen in the quality of the 
work, with the children being trained in the use of many presentation tool and using them fairly naturally. 
On the other hand, they do seem reluctant to try new/different tools that are not the same as those taught 
in school. Another point to note, is that despite being raised in an environment where a paperless office 
is possible, they generate more printout than any previous generation. Even this article was printed out a 
few times for proof-reading before it was ready. 

The final major application for a home computer network is for entertainment. However, this comes 
out more as a mobile conventional entertainment medium, such as the ability to play music or DVDs. The 
use of it to create their own customised CDs is also seen as a big plus. The use of the system for traditional 
computer games is nowhere near as important as others claim although this may be a difference between 
males and females (and my family primarily consists of females!). 

The growth of and change in tools to support these applications has been an interesting observation 
during the past 6 years. The most important issue in the change in the tools has been the growth of 
network bandwidth. Most of the tools have been available for a long time, but the growth in usage relates 
to who else they can interact with. 


Other Observations 

My Home Network gives a reasonable baseline to make a number of observations: 

• CPU performance is becoming less important as most home applications wait for either user inter¬ 
action or network data; 
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• Disk space is never enough, as most applications are writing bigger and bigger output files; but 

• It is not reasonably possible to backup the data that people have, so most of it lives on computers 
forever; 

• Video cards are becoming more important, but only for a limited class of users (i.e. big gamers); 

• Peripherals are not considered during the sale, but are the items that last longer than anything else; 

• Network bandwidth is currently driving the home use of the system; 

• Major software changes occur much slower than hardware changes, on the order of once every 2-3 
years. 


The Future 

So what is the future of these systems. Well, consider the standard system available in two years, it will be a 
dual-core system, although the individual CPU speed will probably be similar to today (i.e. 3-4GHz), with 
2GB high-speed RAM, 1-2TB disk (what do you do with that space?), 4Gbps internal network connections 
with a 50Mbps Internet link. The system will have video card that, itself, will have 1GB RAM and capable 
of a display resolution that the normal human eye will not be able to distinguish from the real thing. 

However, the biggest issue will be what software will drive these systems. Strangely enough, it is most 
likely to be very similar to that used now. Worse still, software that is already 5 years old, is likely in many 
cases to be attempting to run on systems that are orders of magnitude more powerful than ever expected. 

The biggest change likely to be seen is the move from a single CPU to multiple CPUs. Much older 
software expects to be able to perform very low level activities and will be not function correctly in these 
multi-CPU environments. This will drive major software upgrades, but may fall foul of licensing issues 
which still need to be resolved. 


Conclusions 

The changes documented in My Home Network shows how much the standard computer system has 
changed, and gives an indication on what is to come in the future. One thing that is changing, but not 
necessarily adapting to the new hardware is the software environment. Certainly the OSS environment is 
growing and expanding, but more in the usability area. 

A different issue altogether is how the younger generation is adapting to this new environment. It is 
growing up to accept it as natural, making use of these facilities as if they have always been there. 

Of course, the current changes cannot continue indefinitely, but at the present time there is no sign of 
slowdown, and so will be likely to keep pace with predictions for some time to come. 
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Abstract 

This paper seeks to investigate existing Software repositories to see if they contain information which would 
allow the Management level in an organisation to use the FOSS assets in Tactical or Operational man¬ 
agement decisions. The repositories investigated include software and code sharing communities, software 
taxonomies giving information about Free and Open Source Software as well as an industry best practice 
standards. The aim of the continuing related research is to create a set of categories for the classification 
of FOSS so that Management can find value both in increased use and less risk in their exploitation of 
FOSS assets. 


Introduction 

This is a research discussion paper, as part of ongoing research into the use of Free and Open Source Software 
(FOSS) in Organisations; we wish to investigate, if there is a need for a repository for FOSS, specifically 
build with the objectives and needs of the management level in Organisations. Software developers use 
repositories in the development of software, but these are aimed at solving the needs of software developers, 
the tools provide, the functionality and information about the software source code which is, quite rightly, 
built and categorised for the software developer to do their job. What this paper seeks to ask is if there is 
such a repository, focused on the needs of management, and if so what is the meta data in these repositories. 

This paper is part of the initial work; which it is then planned will seek to investigate, what would be 
the management, and/or business needs from this repository. We would investigate; one, if such a need 
exists, and two, what information would be required to be stored in the repository, and what would we use 
as the meta attribute names. 

To scope the discussion, if we divide up the organisation into the levels of Strategic, Tactical, and 
Operational, the governance and informational requirements of the software assets has different information 
needs at each of these levels. The discussion will focus on the Tactical and higher Operational levels, in 
terms of information requirements. The Strategic and lower Operational levels, interact with the Tactical 
and higher Operational levels, however the reason to focus on the Tactical and higher Operational levels 
is that there appears to be an information gap, about the software assets, which could give strategic and 
operational advantage to the organisation. The information needs at the Tactical and higher Operational 
levels are where a richer information picture requirements should assist, and better data could inform 
and enhance strategic needs, as well as hopefully enable actual operational implementations with greater 
accuracy, less risk, more effectiveness, less cost and better alignment to the strategic plan. 

Such a repository is not limited to Open Source software. FOSS is as subset of software in general, it 
is conceivable that the only additions that FOSS would substantiate would be in the expansion of possible 
option values for the meta data fields. Even if this is the case, it is critical to consider if FOSS requires 
additional checks and balances, or processes within an Asset repository. 
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Although it is the intention of the paper to raise discussion and add to the list of desired uses that 
could be found from the repository, a small initial list to help focus discussion is listed here: 

• ICT Planning 

• Checking of Scenario options to fit strategic direction 

• IT governance 

• Development of new software 

• Upgrade / Changes to other software within the organisation 

• Change management planning 

• Release management planning 

• Legal exposure, e.g. compliance, possible patent claims 

• Software contract negotiation, e.g. licence negotiation, support, ownership. 

• Roll out to new division, could be in another legal jurisdiction. 

Software, to which the repository refers, could be in the form of entire applications, such as a Content 
Management System, for example the Australian Governments white branding CMS (Australian Gov¬ 
ernment Information Management Office, 2005). Application suites, such as Open Office, or Internet 
Infrastructure such as Apache web server, or Sendmail. Smaller helper applications such as spell checkers, 
tax calculators, or encryption libraries. Depending on the organisation, including code modules could also 
be desirable, modules such as code to display documents with the character set right to left, check credit 
card numbers, or web services modules. 

There may also be value in extending out the repository to include other information. Such as listing 
out the divisions using of the software, charging arrangements, SLA information, linking to not only source 
code and/or binaries, but training documents, installation guides, or business metrics that could be used. 
Further to this could also be reflections by divisions that have either used or considered using the software, 
to better inform future divisional use, and corporate memory. 


Existing Frameworks / Information Sources 

Avalanche Corporate Technology Cooperative 

The Avalanche Corporate Technology Cooperative 1 is a USA based, members only cooperative formed to 
share Intellectual Property (IP) amongst member organisations, the IP can be in the form of source code 
and software, documentation, workflow or organisational processes. The purpose of the Cooperative is for 
the organisations to gain more effective implementations, to lower development or implementation costs 
and risks by sharing the IP developed rather than gain competitive advantage from developing it with their 
own resources. However the site does not seem to have an overall meta classification of the projects, but 
allows each project to choose how best to share and classify the information pertaining to that project. 


Government Open Code Collaborative (GOCC) 

The GOCC 2 is made up of state and local government entities in the United States, its mission is to 
share software code, processes and information to assist in the first instance the needs of a local or state 
government. The GOCC have build a repository where this information can be shared, the information 
does not seem to be formally classified into sub groups, but is divided into projects, which are self contained. 
The information on each project is also organised on an individual project basis, there does not appear to 
be any formal classification guidelines for projects. 


1 https: //ww. avalancecorporatetechnology.net/ 

2 http://wwv.gocc.gov/ 



EXISTING FRAMEWORKS / INFORMATION SOURCES 


171 


OSTG Software Map Trove Categories 

The Open Source Technology group 3 for their web sites, SourceForge.net and Freshmeat.net, have developed 
high level categories to be able to both find software and to classify attributes of the software: 4 


Development Status 

Environment 

Intended Audience 

License 

Network Environment 

Operating System 

Programming Language 

Topic 

Translations 



Figure 1: OSTG Software Map Trove Categories 

Each of these high level categories has sub categories underneath them, but the audience they are 
intended for is still the software developer, or possibly a systems analyst looking for software to solve a 
specific project requirement. The trove categories do however consider other factors than straight code, 
enabling sorting on items by the Intended Audience (Advanced End Users, Developers, End User / Desktop, 
etc), or by Topic (Artistic Software, Information Management, Security, Utilities, etc). 

EU IDABC Software Taxonomy 

The European Union’s Interchange of Data between Administrations 5 , has developed a taxonomy for the 
classification and finding of information. The high level categories are shown in figure 2, these break into 
subcategories, and the subcategories then contain a list of specific individual software applications. For 
example the Administration and Workflow and Workload management breaks down into Office Suites, 
Desktop software, web tools, content management etc. eGovernment services to citizens contains sub 
categories such as tax declaration, job search, student grants, eDemocracy. Figure 3 shows the details that 
are given for OpenOffice.org as an example of the information on an application 6 . As can be seen, the 
information includes documentation on training, and utilisation, as well as support and information on the 
stability of the application. 

a. Administrative Workflow and Workload management 

B. Communication and management of public sector documents 

C. Statistical tools 

D. eGovernment services to citizens 

E. eGovernment services to Enterprises 

F. eJustice, Legal transparency and visibility 

G. eLearning 

H. Facilities management 

I. Human resource and career development 

J. Hospital management and healthcare 

K. Public e-procurement 

L. Real estate management and Geoinformation 

M. Security, encryption, PKI, identification and authentication 

N. Tourism 

□. Middleware 

P. Programming Languages, Interpreters, Compilers, Development Tools and Operating Systems 

Q. Other 


Figure 2: EU IDABC top level Software Taxonomy categories 


OMG Reusable Asset Specification (RAS) 

The RAS (Object Management Group, 2004) is a framework for enabling the reuse of assets, both at the 
function and module level, although items such as Use case models, test models and DVD’s are specifically 
mentioned. RAS was built to assist with the software engineering of reuse, in the context of Asset-Based 
Development. The standard lists out the UML class specifications of the RAS approach for enabling storage, 
search and retrieval of the artefacts stored in the asset store. The RAS actually can be implemented by a 

3 http://www.ostg.com/ 

4 The Trove categories were built from those listed on the Freshmeat website, browse section, available at 
http://freshmeat.net/browse/18/ 

5 http://europa.ue.int:80/idabc/en/document/3499 
6 http://europa.ue.int:80/idabc/en/document/4109 
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___ 1 

Project name 

OpenOSIice.ot'j; 

Short description 

Gpai05tice.org is a complete and integrated office productivity suite, Includes a program to 
create document, a spreadsheet application, a tool to create multimedia presentations and 
diagrams. H also includes database tools dial support dBASL duiaba.se> and ODBC or JDBC 
compliant databases 

Home page 


Version 

ji.il ,4 

Intended 

audience 

Users 

Developers 

Administrators 

Expert users 

End users 

Atlmimstrulion 

Municipal autltorities 

Provincial administration 

Regional administration 

Central government 

Software license 

GO 

GPL, SISSL, m. 

Ml Bexsu'uwti 

Available 

documentation 

Installation 

Utilisation htio://wv.-w.<XKrautlu*rs.ors4/ : 

Tutorial h>:p:/V w v. *.:mi u i,< ;m 01 oixtsm .nlcc-i t.' 

Documentation protect http-y/d«.tc$Hnct»ai») 0 .c»!ienaffice.on?/ 

Support 

Mailing list mail to: users- subsmbe&ooctKUTicc.m >_• 

eaq teag-.//g?g. v ia<i -vincfwllrv c 

MAC suoiHHt lit(*>;y/oottme.oi>cm>Otcc s.rsvJn nu'/swoourUiim 1 

Native-I.aiteuace confederation hm).//mu«ecls.oiK , ruiftk'c.i>?a/n«i?nt'-lB«£ fuinl 

Operating system 
fs) 

Linux. BSD. Windows95A»8. WindowsNT. Windows 2(HX>.«XP. Windows2093. Macros X>, 
Sun Solaris 

l.angungmi 

Czech, Danish. Dutch, English. Finnish, Fmrch, German, Greek, Hungarian. .Italian. Polish, 
Portuguese, Slovak. Slovene. Spanish. Swedish 

Community sire 

Number of developers 11M >-s 

Nwnfwr of users HX.K10+ 

Status 

Stable 

Contact email 



Figure 3: EU IDABC Software Taxonomy information on OpenOfBce.org 


software appBcation to store software code, and is a practical standard which lists out what is required and 
how each of the sections should link to each other. Although it is currently built and designed more for 
reuse of software assets in the building of code, the scope and classes could be added to the HAS framework 
to meet management needs. In terms of the aims of this paper, a RAS application could be used to provide 
information as part of project planning, the tactical and higher operational aspects of patch and release 
management. 

OMG IT Portfolio Management Specification (ITPMF) 

The ITPMF lists out a framework to form the basis of an IT portfolio, although at this time it is still 
not a completed standard. The information stored includes Agreements, measurement values, contact 
information, dependencies, and overviews of the Asset. The specification lists out the UML diagrams and 
relationships that a software package could implement, although it does not fully list out the attributes or 
set of possible values that would make up an actual software application. This being said the specification 
although close to completion is still being finalised. 

IT Infrastructure Library (ITIL) 

Originally a British Government initiative ITIL, which is now being adopted world wide, has the aim 
of providing best practice guidance for using IT, from a management perspective; in a series of books it 
discusses best practices guidelines for the business management use of IT. ITIL concentrates on descriptions 
of best practice, at a generic level; this is because each organisation will need to implement the practices 
in a different way to get the maximum benefit from their own process. 

One of the ITIL books is Software Asset Management, in this book guidelines are given about the 
storage and management of software assets. Each Asset is a called a Configuration Item (Cl) and the 
information on at Cl is stored in a Configuration Management Database (CMDB), there is an associated 
Definitive Software Library (DSL) which is a physical store of an instance copy of the CI. The suggested 
attributes for a CI in the ITIL are detailed, aimed at possibly a strict interpretation of the CI’s as items 
that need to be inventoried, audited and compliance with the organisations licensing agreements. Figure 
4 shows a brief listing of some of the recommended attributes, for Cl’s. Although detailed the list would 
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(I attributes 

Cl name 

Copy or serial number 

Category (eg software, documentation, media) 
Type teg program module) 

Owner responsible 
Responsibility date 
Accepted date 
(’I relationships 

Change records affecting this Cl 
Problem records affecting this Cl 
incident records affecting this Cl 
Reference Information 
Licence status and counts (including current 
effective use) 

Exception Rags 

Cost (including original cost, depreciation cost, 
and cost centre) 

Licence number 

Reseller confirmation documentation 

Ordered pnxiua. version anti qaanhty 

Software manufacturer 

Platform 

Licensor 

Volume licence programme reference 
1*0 number / date. Invoice number / date 
Reseller 

Country of usage reported 
Proof of Licence 
Media 


Documentation 
Product components 
Security patches installed 
Hardware on which installed 
Country of usage 
Cost-Centre of hardware owner 
Date of last discovery 
Metrics 

Date first discovered 
Updates installed 
Upgrade insurance 
Technology guarantees 

Terms and Conditions 

Source references 
Licensing busis 
Expiry date 

Product substitution rights 
Secondary rights 
Transferability 

Externa! licence transfer requirements 

Source Documentation 

Contracts 

SLAV 

Terms ;»kI Conditions 
Proof of Licence documentation 
Price Uses 

Copies of other relevant internal transaction documents 
Purchase record downloads 


Figure 4: Example List of ITIL attributes for CIs 

seem to concentrate on compliance rather than being able to treat the software as an asset that can be 
leveraged by extracting further value, in being reused and managed. 

Discussion 

The Avalanche Corporate Technology Cooperative and GOCC do not help with the internal management 
of an organisations software assets, while they give both a framework and a repository for organisations 
to share, more than just source code, and the ability to leverage and collaborate on projects of mutual 
interest they do not assist in the tactical or operational management of the assets. 

The EU’s IDABC taxonomy is useful in when looking for information on OSS, and includes rich in¬ 
formation, on aspects such as where documentation is available, support details, if the product is stable 
and the size of the community. However, it does not assist in the management of the software asset once 
adopted. 

In terms of tactical and operational use of the assets in planning future project management, RAS is the 
most powerful framework, since it specifically addresses as part of the artefacts stored, the ability to store 
code, as well as design, analysis and testing components. There is the ability to add to RAS, so that further 
information, that is relevant to the business management rather than the project management, once the 
attributes relevant to the business management use of the asset are known. The ITPMF specification also 
by the Object Management Group, links closely to the RAS, in that it seems to be specifically addressing 
the Asset management aspects of Software components, and is designed with knowledge of the RAS, and 
to be complementary to the RAS. The combination of the two specifications, along with their UML domain 
diagrams gives a good basis for an implementation of a software asset repository. 

The most comprehensive of the frameworks would certainly be the ITIL framework, although that is 
fundamental by the nature of the ITIL mandate. The attributes in ITIL concentrate on what is needed by 
an organisation to be known about the software. Although there is the ability for this to assist in auditing 
the companies’ software assets, and to perhaps be able to target areas of deficiency and therefore the ability 
to either negotiate with vendors, or to retire unused licences, it. may not allow full leverage of the software 
as an asset. 

One solution could of course be to use two repositories, one based on the ITIL and the other on 
RAS. Bundling the information into one repository may in terms of time, cost, complexity may be too 
great, merely keeping it up to date would be a major task, ensuring accuracy might also require a non¬ 
trivial commitment. This of course, would be after the repository was populated. In the current business 
environment where the ability to acquire and divest business units in an organisation is a valid consideration, 
this would means constant work before even day to day activities could be based upon the repository. 
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Further Research 

Going forward, there is a need to build an initial list of the meta data attributes, which would form the 
basis for future discussion on the repository. Investigating other methodologies such as CMM and the 
COBIT framework might also reveal additional attributes and considerations for the repository. 

Further investigation of what it is that management wants to know about its software assets is critical. 
Then mapping of the business needs and requirements, to attributes names and relationships in the meta 
data. 

Further to the need of both attributes and business needs is to work on mappings and processes based 
upon specific values of the attributes, e.g. if you have binaries which are licensed under the GNU GPL, 
then it is permissible to use it on or with software binaries which are licensed under the BSD licence, but 
you may not be able to do that if you wish to use the source code. 

There is also study for further benefit, using such a repository internally may give benefit, but if this 
could be released to vendors bidding on new projects, the vendors may be able to build their bid around 
existing organisational assets, lowering cost and perhaps risk to both parties. 


Conclusion 

The ultimate question for this research is; Is there value to management? Would the organisation at the 
Tactical and Operational levels be able to extract business advantage from such a repository? 

Given the importance of software in a business environment today, and the increased complexity in its 
management, interaction with other software and the penalties to organisations if the IT is interrupted, as 
well as ongoing compliance issues, be it to increasingly complex licences, partnerships and regulation. The 
management of a repository of software assets which is dedicated to software, and the issues pertaining to 
it would seem a reasonable business decision. To go further than this and build a repository which allows 
greater knowledge of the software assets and the leveraged ability to gain value or lessen risk would enable 
added business value which is worth the cost of implementation. 
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Abstract 

The Content Management System - or CMS - has grown to become the critical tool for managing and 
maintaining the online presence of many of the world’s leading Internet sites. 

Forward thinking organisations are following this lead, and are shifting away from the outmoded 
paradigms of dedicated “webmasters” and outsourced website maintenance contracts toward decentral¬ 
isation of web activities and direct management of content areas by relevant stakeholders within the or¬ 
ganisation. 

A CMS is the tool required to satisfy these needs. It provides the processes and workflows required to 
organise, categorise and structure information resources so that they can be stored, published, and reused 
in multiple ways. A good CMS removes the bottleneck of setting content “live” from technical users to 
ordinary people, and a well aligned system can mean the difference between online success and failure. 

Successful implementation and uptake of a CMS brings a unique set of business challenges in terms of 
initial evaluation, development and integration strategy, change control measures, dissemination of skills, 
and devolution of content management tasks to appropriate stakeholders within the organisation. 

This presentation will cover the requirements for developing a successful content management strategy 
in your organisation from evaluating an appropriate CMS from the wide array available (both open source 
and proprietary), “upscaling” from a static site to a CMS, and implementation and maintenance of the 
CMS. 


Introduction 

A ‘Content Management System’ (or CMS) is an application which allows end users to create, publish and 
maintain the digital content and information assets of an organisation. 

The term ‘CMS’ has been in use for many years, and has described a correspondingly wide array of 
application software. More recently however ‘CMS’ has been used to refer specifically to systems for Web 
Content Management (or WCM). 

As it relates to Web Content Management then, the term ‘CMS’ refers to the tool or tools which make 
it possible for non-technical users to store and publish content to a website. The CMS serves as a store 
for a wide range of content - including text, images, reports, video, audio, transactional data, catalog and 
code. 

In larger organisations, the CMS has already become a tactical and non- discretionary expenditure. 
And within smaller organisations, the CMS is being increasingly viewed as strategic core investment as 
they deal with accelerating business velocities, consolidation of redundant content management systems, 
exponential growth of content and lastly compliance issues (both mandated and perceived). 

A CMS simplifies the business process of content production by empowering content contributors to 
perform content creation, publishing, and maintenance-related tasks without requiring technical skills. The 
CMS is responsible for tracking the location of, and relationships between, information assets in a central 
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repository or file system. And as the amount of content and/or the number of contributors grows large, 
the CMS helps to collect, create, and aggregate content in ways that make it easy to manage. 

Irrespective of the size of a CMS project, there are a number of steps that time has shown to differentiate 
between successful and unsuccessful deployments. These steps will now be briefly investigated. 


Step 1: Design 

The design phase is usually a progressive, high-level and forward thinking one; and not all recommendations 
or findings from the design stage need to be implemented immediately. Rather, the design phase of your 
CMS strategy provides a place to capture requirements from all stakeholders of the system, and to associate 
priorities to particular requirements so that timely and effective implementation can ensue. 

Common tasks undertaken during the design phase range from the core systems design decisions such 
as choice of topology, deployment model and systems integration through to presentation layer aspects of 
graphic design, interface design, workflow design and content design. 


CMS Topology 

Meta Group describes Content Management as; 

“.. .a complex blend of functionality, including the acquisition, management, assembly, review 
and approval, effective publishing, retention and security of information bound for any of an 
organization’s .. .Internet, intranet, or extranet venues.” 

Clearly our choice of topology is very important to the design of our overall solution, as it have some 
of the largest downstream impacts on the deployment model, business logic, workflows, content types, 
accessibility requirements and technology requirements of the solution. Broadly speaking, we can choose a 
topology based on our target audience - either B2C (Internet), B2E (Intranet) or B2B (Extranet). 

Deployment Model 

Self-Managed : A traditional CMS is usually either downloadable from the web or provided as a boxed 
application and must be installed to a server. While this may offer simplified systems integration, it 
may also require a greater degree of System Administration. 

ASP : In this scenario the CMS is provided via an Application Service Provider. They usually host and 
maintain the solution, often meaning less upfront hardware and administration costs. 

Deployed : This refers to an ASP solution installed within a user’s own environment or Intranet. 

Requirements Gathering 

In the requirements gathering phase, the technology requirements are firstly identified including existing 
backend systems such as directories and databases, available hosting architectures and any legacy applica¬ 
tions or databases. Following this key stakeholders are identified, and their content requirements of each 
are captured and recorded. Once all requirements have been gathered, these can be weighted and assigned 
priorities and then integrated into an overall project plan for the development and implementation phase 
of the solution. 


Step 2: Evaluation 

The most worthwhile investment of time and resources you can make in your overall CMS strategy is to 
determine your business requirements up front, and then comprehensively evaluate the list of available 
products against these requirements. 

However this can also be one of the most complex tasks in your overall strategy. At present, the CMS 
marketplace is one of the most saturated and competitive of the ICT world. There are literally hundreds 
of different offerings, each with different capabilities and strengths, and very little consistency between 
vendors. The marketplace is also very dynamic; with acquisitions, mergers, failures and an ever changing 
playing field of technical specifications and features. Moreover, there is a closing gap between the features 
offered by many of the heavyweight proprietary CMS solutions such as Interwoven Teamsite, Vignette, Red 
Dot, Documentum et al. and their Open Source counterparts such as Plone, Zope, CPS and Midgard. 
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For larger projects, the only real way to evaluate the suitability of one or other offering is to conduct 
a formal review of requirements and then perform a hands on evaluation of the system. Irrespective of 
the size of the project however, the most important thing to remember is to focus on your organisation’s 
unique requirements, rather than solely focusing on the features provided by any particular CMS. 

Project Size 

Smaller CMS solutions are targeted at single web authors working one or a few websites, and mostly 
facilitate easy creation and publication of web based content. Enterprise CMS solutions on the other 
hand usually control hundreds of thousands of information assets on hundreds of websites with hundreds 
or even thousands of contributors. Team CMSs sit in between these two extremes, and are also called 
Departmental or Mid-market Systems. They are usually deployed within corporate departments, SMEs 
and midsize Government Departments. 

Team and Enterprise Content Management Systems ordinarily allow a team of contributors to work on 
the same content without conflicting - via check- in/check-out mechanisms and workflow control. These 
systems are usually deployed to facilitate collaborative creation of digital content. 

With most Enterprise CMS solutions, information assets are loaded into the system and can be struc¬ 
tured and output in a number of different ways. This notion of ‘Single Source Publishing’ (also called 
‘Content Reuse’) allows an item to be edited in one place and be published instantly in many places. It 
also means that the different versions of the content can be formatted properly for delivery across multiple 
channels including the web (HTML and PDF), print, wireless handheld devices, cell phones, braille displays 
and screen readers. 

Most Enterprise CMS solutions further provide the tools necessary for ‘document lifecycle’ which in¬ 
cludes versioning, scheduling (allowing content to appear and disappear at preset times) and archiving of 
expired content. 

Function 

Besides the size of a particular CMS the systems can be further grouped in terms of function. It is important 
to establish the primary function for the CMS up front, as a system that is not particularly well aligned 
to the task at hand will increase the chances of a failed project. Broadly speaking the main functional 
classificaitons of Web CMS can be grouped into; 

WCMS - Web Content Management System 

LMS - Learning Management System 

EDMS - Electronic Document Management System 

Web Portal - Aggregation of content from multiple sources 

Wiki - Collaborative Development of Content by Multiple Authors 

Weblog - Usually for Personal Publishing 

Hybrid - A combination of the above with possibly other functions 

Feature Based Comparison 

As part of your evaluation it is best to firstly evaluate all possible options from a feature-based perspective. 
Online resources such as CMS Matrix (www.cmsmatrix.org) et al. provide an unbiased and level playing 
field for yes/no and quantitative style comparisons of features supported by the various alternatives. 

While feature based data can provide a rough overview of the fitness for purpose of a particular product 
to a project, it is important to realise that it will not provide any qualitative feedback on how well these 
particular features are implemented, nor how easily the particular implementation will map to the relevant 
stakeholders technological and training capabilities. 

A feature based comparison does however, provide a first port-of-call in conducting an analysis, and 
will quickly establish a shortlist of candidates that will be best suited to meeting the requirements of a 
project. In drawing a decision from a market offering such a large number of varied solutions, it is desirable 
to de-scope as many possibilities up front as possible to ensure that the additional effort required for a 
more rigorous evaluation of candidate systems is expended only on the most closely aligned systems. The 
following list provides a common list of CMS features which can be readily used to conduct a feature based 
comparison: 
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Templating 

Separation of Content and Presentation 

Workflow 

Standards Compliance 

Versioning 

Indexing 

Templating 

Search 

Archiving 

WYSIWIG Editing 

Repurposing/Single Source Publishing 

Internationalisation 


It is always worth conducting an impartial review of a potential shortlist of CMS candidates by a vendor 
neutral company. Many vendors will push their systems based on feature sets, and will know exactly what 
solution they are going to sell you before they walk in the door. 

Requirements based comparison 

Requirements based comparisons are always more effective than feature based comparisons, although gen¬ 
erally a lot more resource intensive. It is important to highlight that the two techniques are complimentary. 
The list of features offered by the various CMS offerings today is immense, and many of the terms used to 
describe these features are used interchangeably or reworded by vendors attempting to differentiate their 
product from similar offerings. 

In addition, the abstract nature of many of the concepts relating to Content Management means that 
there is no such thing as a ‘standard’ way to implement many features. Instead, there are many vastly 
different implementations which means that features such as ‘workflow’ or ‘collaboration’ vary significantly 
between different systems. This makes it very difficult to conduct an accurate comparison of any two 
systems without actually testing them. 


Step 3: Development 

Once a suitable CMS has been selected from the evaluation process, it is time to commence developing 
your solution. Most situations requiring a CMS solution usually also have an associated body of existing 
content which must be dealt with. Therefore one of the critical deliverables of the development phase is 
to develop a thoroughly tested ‘migration path’. 

Conventional systems development activities usually also occur at this phase, although these do not 
differ markedly from standard project. Rather than cover all aspects of standard development, we will 
briefly explore development activities specific to a Content Management System project. 


Structural Development 

The structural development phase is where the site skeleton is developed. The deliverable of this activity 
is the ‘Sitemap’ of the CMS. Where there is existing content, a ‘content audit’ should be used to ensure 
that the new structure maps to the old structure. This is a process of mapping out the already-existing 
content and matching it to the newly developed sitemap. The audit also helps to establish the scale of the 
task at hand and can be used as a management tool in the content creation process. 

Custom Content Types 

Most CMS solutions will come prepackaged with a generic set of content types such as images, documents, 
and news items. However most projects will also have a list of custom content requirements, such as press 
releases, events or tenders. Often generic content types can be repurposed or combined to create new types, 
but specialised content types may have to be built from the ground up. Also at this stage, any metadata, 
taxonomies or thesauri particular to content types are developed. The complexity of developing custom 
content types and metadata schema will vary substantially between solutions. 


Migration Path 

As mentioned, development of a robust and reusable migration path is one the most critical success factors 
to successful uptake of a system. Many CMS implementations fail despite sound design and evaluations, 
because a poor migration path introduces a switching cost that makes it either very difficult or impossible to 
affect a realistic change. One of the most important factors to understand in developing a sound migration 
path is the quality of the legacy content to be migrated. 

Whatever the case, there are a three general qualities of legacy content that makes it especially chal¬ 
lenging to address within a new CMS. 
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Firstly, legacy content tends to be inconsistent in most cases, and completely unstructured in bad 
cases. Usually, the requirement for the CMS has come about as a result of the shortcomings of less robust 
technologies. Moreover, much legacy content comes from a time within an organisation when there were 
less skills or when the long term utility of the data had not been fully recognised or understood. 

Secondly, the quality of the data tends to be quite poor. In particular, the content and presentation of 
the data tends to be enmeshed and often ad- hoc markup cannot be easily parsed, interpreted or scripted. 
One of the main reasons for opting for a Content Management System is to manage the content - and a 
large part of this comes in terms of maintaining this separation between content and presentation. 

Finally, legacy content tends to disaggregated and scattered across an organisation. In smaller or¬ 
ganisations, content may not have been collated to a centrally accessible point in the first place, and in 
larger organisations, content may have been centralised at multiple points, systems or sites and then glued 
together in an ad-hoc fashion. Accordingly, one of the most important development considerations for the 
migration path is to ensure that it adequately captures all data required in the new CMS. 


Legacy Systems Integration 

Content Management Systems often also need to integrate with external systems for many different reasons. 
Directory servers (LDAP and X.500) may be required to provide authentication in environments where 
there is a large base of users or organisational groups. Existing database solutions, groupware suites, 
document management systems or legacy applications may also need to be repurposed and integrated into 
the Content Management System. 


Step 4: Implementation 

The implementation phase deals primarily with establishing the production environment and bringing 
the various deliverables of the development phase together in this environment. Following this, the CMS 
structure is implemented and lastly the data migration onto the new system is performed if required. 
Following setup and transfer, the skills transfer required for administration, usage and ongoing maintenance 
of the system will need to disseminate the relevant stakeholders. 

Site Structure, Security and Permissions 

The Sitemap produced during the development phase is implemented in the final production environment. 
Following this, the users, groups and the roles performed by each are implemented within the assigned to 
the various areas within the site. 

Content Migration 

Standard change control measures such as a code freeze or staged cut-across will be used in conjunction 
with the migration path from the development phase to perform the final data migration. As part of the 
data migration phase, it is good practice to ensure that a responsible party exists on the receiving end of 
the migration for maintaining each particular site area. For areas where there are no pre-existing users or 
groups, it is worth trying to establish a responsible user or group or else consider deprecating the content. 

Skills Transfer 

Training and handover to end users will have the greatest impacts in terms of long term utility and 
sustainability of a CMS following its deployment. Some CMSs edit unstructured content, whole documents 
or web pages (usually HTML), others edit structured content, with a content template for a page and 
individual content elements (usually XML). Therefore, the cognitive load placed on your end users will 
vary substantially between offerings. It is worth noting that there is a direct correlation in the most cases 
between cognitive load and long term sustainability of a solution - that is, the easier it is to operate a 
system; the more likely it is that it will be successful in the long term. 


Step 5: Maintenance 

Following a successful implementation and dissemination of skills to key stakeholders within an organisa¬ 
tion, there are several routine maintenance tasks that should be periodically performed. Again, as with 
development, there are routine maintenance activities as well as CMS specific maintenance activities. 
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One of the first CMS maintenance activities usually performed directly after implementation is an 
accessibility review - in which the site is analysed and rated in terms of its accessibility to all end users. Site 
statistics are usually also reviewed periodically to ascertain what information is being regularly requested 
and can be used to optionally restructure and reshape the site and make information retrieval more efficient. 

Lastly, CMS maintenance is focused heavily with the concept of ‘optimisation’; in terms of overall 
speed, asset caching and search engine optimisation. All of these areas should be periodically reviewed to 
ensure that the CMS is performing at its best. 


Conclusion 

Every CMS project carries with it a unique set of requirements, and in a problem domain as diverse and 
abstract as ‘Content Management’ there is no such thing as a ‘one-size-fits-all’ solution. Therefore, to be 
confident of achieving the best possible outcome for your project, it is important to allocate sufficient time 
and resources to designing, selecting, developing, implementing and maintaining your CMS. The results 
will be well worth the investment. 
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Abstract 

If security, stability, freedom and cost are important to you, then at the very least, you should be looking 
into the non-commercial (free Open Source) alternatives. If you value competition and innovation, then 
it’s in your best interest to support Open Source. It’s no secret that the Internet relies heavily on Open 
Source software such as BIND, Sendmail, Apache and OpenSSH. However, if you have not integrated Open 
Source into your IT infrastructure by now, then you are probably paying way too much in IT infrastructure 
costs. Major Investment Banks have picked up on this. We are seeing more Governments adopt Open 
Source. Very large vendors have a vested interest in its success. Would you be surprized to know that 
your competitors are probably saving money using it? The following is a true account of Open Source 
integration into one of the largest and oldest services firms in the World. 

Introduction 

This paper will explain how Open Source systems were integrated in an all Windows environment with no 
interoperability issues. Our primary concern was to restore stability and improve security. The by-product 
were significant savings and considerably less dependence on commercial hardware and software. 


Problems 

Imagine, what you would do if you inherited an office of workstations and servers where data loss, network 
congestion and server downtime were common occurrences. What if you were not given the luxury of 
documentation? It is not very often that one is given the opportunity to clean house but we knew that 
rebuilding an IT infrastructure, all the while maintaining business as usual, was going to be challenging 
and non-trivial. 

The following were some of the very pressing issues that we had to deal with: 

• An unmanageable Checkpoint Firewall 

• A corrupt Active Directory on one unhealthy Primary Domain Controller 

• Network congestion and packet loss due to packet fragmentation issues 

• Too many applications concentrated on just a few clustered servers 

• An office of neglected PCs 
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• Windows Servers directly exposed to the Internet 

• An unpleasant and painfully slow VPN experience for Remote Access users 

Objectives 

With very limited resources, our team had to rebuild the whole network of servers and a new domain from 
the ground up. Our objectives were as follows: 

• Restore network, server and application stability 

• Tighten and increase security at all levels 

• Reduce IT infrastructure expenditures 

• Document everything that was done 

• Create a strong IT Team by fostering a teaching/coaching work environment 

• Build a better relationship with the users 


Guidelines and Restrictions 

We did not incorporate Open Source Systems into our IT infrastructure because we could. We didn’t have 
a choice as most of the Windows servers were just too resource hungry for the older servers that we had 
available to use. More over, we had to use anything that was available to us as we were also explicitly told 
not to spend any money unless it was absolutely necessary. Unfortunately for us, the previous IT Manager 
took advantage of his position. Therefore, our use of Open Source was actually a necessity. Nevertheless, 
we used the following checklist to guide us on that decision: 

1. If security was a concern, then we used a more secure alternative to Windows. 

2. If cost was a factor either for software licenses, service/support contracts or hardware, then we 
considered the Open Source alternatives. 

3. If stability and uptime was important, then this was taken into account. 

4. If all three points above qualified, then the last question to be answered before replacing any Windows 
based application or service was the following. Will there be any interoperability issues? That is, 
will there be any downside to replacing Windows and implementing a more secure, stable, cheaper 
Open Source alternative? If the answer to the last question was “NO”, then we used Open Source 
when appropriate. 

OpenBSD was the Open Source operating system that was used. Alternatively, any other Open Source 
operating systems could have been used. At the end of the day, your familiarity with the operating system, 
its security track record and licensing/use restrictions should be considered prior to any implementation. 


Building the network from the ground up; the switch to Open 
Source 

Firewall 

The first thing that we needed to do was to replace the unmanageable Checkpoint firewall with an OpenBSD 
firewall. We were told that the Checkpoint firewall became unmanageable after a security patch was applied. 
Whether this was true or not was immaterial. There was no way to log into the Management Console in 
order to manage the firewall. On top of that, the Checkpoint firewall had the client, enforcement and 
management modules all installed on the same server; a Windows 2000 Server at that. To our chagrin, 
there was no detailed documentation of the existing rule set. Just about everything about the network had 
to be deduced and pieced together with bits of information wherever we could get it. 

About a month after the Checkpoint firewall was replaced with an OpenBSD firewall, we were informed 
that that was not the “Firm” standard firewall and that we would have to put back the Checkpoint firewall 
as soon as possible. We setup and configured a new Checkpoint firewall. However, not too long after 
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putting it in production there was an outbreak of viruses (’nachi’, ’msblaster’ & ’sobig’ viruses) causing a 
denial of service. OpenBSD to the rescue again. Imagine that, an OpenBSD firewall running on an old 
PII 400 MHz processor out in front protecting a Checkpoint firewall because it was going to 100 

One of the many benefits to running an OpenBSD firewall besides its security track record, sophisticated 
firewalling capabilities, bandwidth control, etc, is the inclusion of Common Address Redundancy Protocol 
(CARP) that was developed by Ryan McBride. In short, with CARP and PFSYNC (packet filter state 
table logging interface), we can run multiple firewalls that act as one resilient firewall. If we need to take 
down one firewall for hardware upgrades, then we can do this at anytime. The backup firewall just takes 
over seamlessly as if nothing ever happened. Now there is no Internet downtime. 


DNS and DHCP 


DNS and DHCP was integrated with Windows Active Directory and were running on Windows Domain 
Controllers. Unfortunately, these Domain Controllers were not replicating. We discovered that Active 
Directory mysteriously became corrupt not too long before the previous IT Manager’s imminent departure 
and the only good Active Directory tape backup was done six months prior. It was a precarious situation 
to say the least as the whole office was dependent on one last remaining Primary Domain Controller that 
was on its last legs. Nothing could be done to repair the situation. This was a Windows 2000 Server that 
was an upgrade from a previous NT4 Domain Controller with a 4 GB drive. The problem was that there 
was absolutely no room left to defragment the drive and it was as red as Rudolf’s nose. We made the 
decision to separate DNS and DHCP from Active Directory as we new it would help us in our transition 
to a new Domain. We also did not want to be put in the same situation ever again. We setup dedicated 
OpenBSD boxes running BIND 9 and DHCP. 

The following is an example of all that was needed from each Active Directory Domain Controller. 


Microsoft Specific Resource Records copied from netiogon.dns from the PDC (YEBISU) 


.privdomain.com. 600 
_ldap._tcp.privdomain.com. 600 
_ldap._tcp.Default-First-Site-Name._sites.privdomain.com. 600 
_ldap._tcp.pdc._msdcs.privdomain.com. 600 
_ldap._tcp.gc._msdcs.privdomain.com. 600 
_ldap._tcp.Default-First-Site-Name..sites.gc._msdcs.privdomain.com. 600 
_ldap._tcp.2f94ddl7-9222-4beb-al62-033f57f9a75f.domains._msdcs.privdomain.com. 600 
gc._msdcs.privdomain.com. 600 
f8154056-84a8-4a60-b470-132343747c6o._msdc s.privdomain.com. 600 
_kerberos._tcp.dc._msdcs.privdomain.com. 600 
_korberos._tcp.Default-First-Site-Hame..sites.dc..msdcs.privdomain.com. 600 
_ldap._tcp.dc..msdcs.privdomain.com. 600 
_ldap._tcp.Default-First-Site-Name..sites.dc._msdcs.privdomain.com. 600 
_kerberos._tcp.privdomain.com. 600 
_kerberos._tcp.Default-First-Site-Name..sites .privdomain.com. 600 
_gc._tcp.privdomain.com. 600 
_gc..tcp.Dofault-First-Site-Name._sites.privdomain.com. 600 
_kerberos._udp.privdomain.com. 600 
_kpasswd._tcp.privdomain.com. 600 
_kpassud._udp.privdomain.com. 600 


IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 

IN 


A 192.168.66.50 

SRV 0 100 389 yebisu.privdomsdn.com. 
SRV 0 100 389 yebisu.privdomain.com. 
SRV 0 100 389 yebisu.privdomain.com. 
SRV 0 100 3268 yebisu.privdomain.com. 
SRV 0 100 3268 yebisu.privdomain.com. 
SRV 0 100 389 yebisu.privdomain.com. 

A 192.168.65.50 

CNAME yebisu.privdomain.com. 

SRV 0 100 88 yebisu.privdomain.com. 
SRV 0 100 88 yebisu.privdomain.com. 
SRV 0 100 389 yebisu.privdomain.com. 
SRV 0 100 389 yebisu.privdomain.com. 
SRV 0 100 88 yebisu.privdomain.com. 
SRV 0 100 88 yebisu.privdomain.com. 
SRV 0 100 3268 yebisu.privdomain.com. 
SRV 0 100 3268 yebisu.privdomain.com. 
SRV 0 100 88 yebisu.privdomain.com. 
SRV 0 100 464 yebisu.privdomain.com. 
SRV 0 100 464 yebisu.privdomain.com. 


All the workstations were given names that were based on their MAC addresses. We issued static 
IP addresses and associated them with the users’ telephone extensions. Therefore if a user’s telephone 
extension is 6529, then the user’s IP address would be 192.168.65.29. We would create an alias for the 
machine name based on the user’s login name. The forward and reverse Resource Records would like the 
following: 

• Forward Zone 


0002551A3B0E.priv.domain.com. IN A 192.168.65.29 

muemura IN CNAME 0002551A3B0E.priv.domain.com. 

• Reverse Zone 

29.65.168.192.in-addr.arpa. IN PTR muemura.priv.domain.com. 

If a host on the network was exhibiting strange behavior, we didn’t have to rely on switch port in¬ 
formation to determine the location of the problem host/user. The firewall logs became very rich with 
information at a glance. We found that we were able to troubleshoot and find problem hosts a lot more 
efficiently and effectively after doing this. 

Another important change was to our external Domain Name servers running Windows protected or 
not by Zone Alarm. We replaced all Windows DNS servers with fully firewalled OpenBSD Servers running 
split-view DNS with Bind 9 placed within a DMZ. The split-view DNS allowed us to have our internal 
hosts use our external DNS servers for both internal and external name resolution without the use of 
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DNS forwarders. Prior to this change, all internal hosts used internal DNS servers based in Sydney for all 
internal and external DNS name resolution. At that time the latency to Sydney from Tokyo was about 600 
ms using our internal Global Wide Area Network (GWAN) which was fed through a T1 line. Furthermore, 
there was quite a lot of packet loss mainly due to fragmentation as we were on a site-to-site-VPN over the 
Internet and the MTU on both Cisco VPN gateways/routers were still set at 1500. For years, the office 
was complaining of speed issues. As soon as we pointed the hosts to use our own external DNS Servers 
for name resolution, the difference to them was like night and day. Their speed issues seemed to have 
disappeared overnight and in fact, we went from a latency of 600 ms down to 6 ms and from a 1.5 Mbps 
pipe for name resolution via Sydney to a 100 Mbps pipe directly connected to the Internet. 


Web Server 

Even though we could have stripped down, hardened and locked down IIS, we just did not feel comfortable 
with the combination of IIS on Windows. Both have been notorious for bugs that have led to serious 
exploits and propagation of viruses and worms. The office website was static html with a little flash and 
some JavaScript. It was trivial to move the website from IIS on Windows to Apache on OpenBSD. The 
version of Apache that comes with OpenBSD is a forked version (Apache/1.3.29) that is running privilege 
revocated in order to avoid attacks and escalation of privilege on this setuid daemon. The Apache server is 
running chroot by default. That is, it “is locked into a particular directory and unable to wander around 
the rest of the directory tree, and sees that directory as its “/” (root) directory. Apache starts, opens its 
log files, binds to its TCP ports (though, it doesn’t accept data yet), and reads its configuration. Next, it 
locks itself into /var/www and drops privileges, then starts to accept requests. This means all files served 
and used by Apache must be in the /var/www directory. This helps security tremendously - should there 
be a security issue with Apache, the damage will be confined to a single directory with only “read only” 
permissions and no resources to cause mischief with.” [1] 

Furthermore, this version of Apache has been code audited with many bug fixes. As a result, it runs 
almost 7,000 lines of code less than the original Apache 1.3.29. 

$ diff -ru apache_l.3.29 /usr/src/usr.sbin/httpd I wc -1 
6916 

Besides only having port 80 open, we have a cron job that periodically runs a shell script [2] that 
searches the log files for hacking attempts. When IP addresses are found that have tried to execute any 
of the following commands, we automatically black list those IP addresses. We can do this because our 
OpenBSD web server is fully firewalled. 

SEARCH / 

/_vti_bin/ 

"GET /www/scripts/ 
cmd .exe 
root .exe 

We have also taken extra precautionary measures to ensure that our web server is not subject to a 
Distributed Denial of Service (DDoS) by placing it in its own DMZ behind two OpenBSD Firewalls that 
are doing SYN Proxy and adaptive timeouts when reaching set state limit thresholds. Connection attempts 
to the web server must complete the TCP three-way handshake before getting to the web server. All 
legitimate connections are passed and SYN Flood attacks (and spoofed IP addresses) are unceremoniously 
dropped. This ensures that we do not black list spoofed IP addresses as usually the case for SYN Flood 
attacks. [3] 

This setup also gives us load balancing capability but our one web server doesn’t get the amount of 
traffic needed to justify adding more than a live backup web server to the fold. At present, we have one 
MASTER web server and one live BACKUP for redundancy. If the primary web server goes down or 
is taken off-line for maintenance, the backup takes over automatically. We can easily scale this if need 
be without changes to our infrastructure. For redundancy, load balancing or if we were serving dynamic 
database driven content, all we would need to do is add more servers and do a source-hash on the CARP 
firewalls so that clients are always directed to the same web server for the duration of their session. 

Remote Access 

VPN access in the past used to be a very unpleasant experience because it was painfully slow. Remote 
users in Tokyo had to go through Sydney in order to get back to internal resources in Tokyo. Obviously 
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the distance was a big factor however there was also considerable packet loss due to fragmentation along 
the Sydney - Tokyo VPN route. In fact, it was so slow that an alternative, “GoToMyPC” was used but 
even this was not very fast. 

One of the first things that we did was to remove “GoToMyPC” for remote access. It was circumventing 
our Firm’s Security Policy on Remote Access but more importantly, it was deemed a security risk after 
we discovered the “GoToMyPC” hosts continually polling various Internet “GoToMyPC” servers. In its 
place, we setup two fully firewalled OpenSSH servers situated within a DMZ that would allow specific 
applications such as Remote Desktop Client or Lotus Notes to be tunneled through an application layer 
encrypted tunnel. We have been using this form of Secure Remote Access for more than two years now, 
rock solid, dependable and secure. 

We use a public/private key system with a strong passphrase for dual factor authentication for all 
users. No username/password authentication is allowed. Upon successful ssh authentication, their unique 
and very strict firewall rule set is loaded, the client receives an authenticating shell (authpf - no real shell 
is given) whereby the only command that they are allowed to enter is <CTRL>+c which would then 
gracefully end their ssh session. At this point, we have fine grain control over what the user can and 
cannot do. Generally we only allow remote users to tunnel either mail or Remote Desktop Connections 
to their own PCs or to a Terminal Server running in Application Server mode. The Authentication logs 
are scanned every few minutes for bad username login attempts, these IP addresses are then automatically 
added to the firewall to deny further login attempts. [4] 

The following is a typical authentication log entry: 

Aug 25 18:16:19 sshOl sshd[32680]: Failed password for invalid user root from 211.234.112.140 port 33630 ssh2 

This is the corresponding ssh_blocker log entry: 

Aug 25 18:16:32: Infected host detected 211.234.112.140 - Adding IP Address to the blocked table: 1/1 addresses added. 

Server uptime and overall productivity and efficiency gains 

Historically this office has had problems with servers and applications going down while people were 
working. This translated into data loss, costs due to no productivity or idleness and user frustration and 
aggravation. There were accounts of applications and email that were not accessible for days besides the 
constant and unexpected downtime of applications from time to time. 

One of the main reasons for this was that most of the applications that were used were loaded and 
served from too few servers that were dependent on each other. The servers were powerful enough but 
if an application crashed or a program update or security patch was made, it usually required a reboot 
meaning that all the applications were temporarily off-line during this time. Unfortunately, this happened 
more than several times per month for many years, long before we given responsibility over the network 
and servers. 

In order to fix this problem, we rearranged the server resources and spread the impact of any one 
application over many servers. If we had to take one application or server down for whatever reason, 
it would have a minimal effect on productivity. We also planned downtime for server maintenance and 
security patches for either very early in the morning, very late at night or on the weekends. The only other 
reason for downtime was due to migrating applications from one server to another. 

Secure Wireless Networks 

After we had completely rebuilt the office IT infrastructure from the ground up, we had some time to work 
on other projects. One of the more interesting projects had to do with building a secure wireless network 
for our office. Serendipitously, it turned out to be one of the most robust, user friendly, scalable, inex¬ 
pensive and ultimately the most secure wireless network solution available when compared to commercial 
alternatives. 

The main reason that it was so inexpensive was that we did not have to purchase any special hardware or 
software. Once again OpenBSD became the center piece of this solution acting as a fully firewalled Access 
Point providing strong authentication through OpenSSH and strong encryption using IPsec/ISAKMP. All 
other commercial solutions forced a lock-in of some sort of either proprietary hardware and/or software. 
On top of that there were usually per device licenses and per node modules for added functionality but 
often at a steep price. 

It was robust and scalable because each access point was independent of each other. We could add 
access points in areas where the concentration of wireless users was very high distributing the load evenly 
throughout those access points. We had fine grain control over what the user could and could not do to 
the point of automatically kicking the user off of the wireless network indefinitely if we saw any kind of 
unusual activity from the user’s laptop. 
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It was user friendly because all the user had to do was double-click an icon on the their Windows 
desktop. This automatically connected the wireless laptop to the nearest Access Point, then establishes 
the IPsec encryption. Once encryption was established the authentication process was initiated. At that 
point, the user would be asked to enter his/her passphrase in order to validate the user’s access to the 
wireless network. 

It was so demonstrably easy and secure that we were asked to help roll out the same solution to other 
countries that wanted to deploy a similar secure wireless network as it was the only solution that addressed 
the Firm’s Baseline Security Standard: strong encryption, strong authentication, firewall protection and 
integrated with a intrusion detection system. This solution was a great example of Open Source clearly 
way out in front of commercial alternatives. 


No more downtime or data loss; improved efficiency and produc¬ 
tivity all equated to savings 

IT expenditures such as hardware, software, service contracts and third party vendor provided solutions 
were close to USD $10,000 a month on average over 5 years. After the switch to Open Source, total IT 
expenditures were less than USD $10,000 for an entire fiscal year. The elimination of downtime and data 
loss along with efficiency and productivity gains were so noticeable in the first year that in the beginning 
of the second year the whole office received new workstations and dual 19” Flat Screen Monitors. Needless 
to say, the staff were that much more productive in the second year because of the powerful computers 
and dual screens. 


Summary 

By the time we were finished with the migration of services from Windows to OpenBSD, we actually 
completed two migrations: one to the old generation servers and back again to the newer high-end servers 
when they were available again. Without integrating Open Source into our IT infrastructure, what was 
accomplished over a half a year would not have been possible. We hope that this paper becomes an 
example and if not an inspiration for other companies and organizations. It should be obvious that those 
without a strategy for implementing Open Source into their IT infrastructure in 2005, will be paying way 
too much in 2006 and beyond. More over, the main benefits besides cost reduction are increased security, 
increased stability, less dependence on commercial hardware and/or software and a happy marriage between 
Microsoft and alternative Open Source Programs and Operating Systems with no interoperability issues. 
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Abstract 

Wireless Networks are bliss to users and the bane of Security Administrators. As wireless technology 
pushes closer toward wired speeds, this will become the preferred medium for Internet access for many, 
if it is not already. Unfortunately, most wireless networks are insecure by default and security seems to 
be an afterthought for the users, hardware and software vendors alike. More over, even with security 
features used, most Access Points use very weak encryption, little or no authentication methods and have 
no built-in firewall technology. So how can businesses utilize wireless technology and still be able to protect 
confidential information from unauthorized access? This paper describes one Open Source solution that 
addresses the above security concerns. 

Today there are Open Source software and systems that rival commercial alternatives. This is especially 
true in the Security World. The Secure Wireless Solution that will be detailed in this paper is one such 
example. No commercial alternative to date has proved to be as secure, has the same security track record, 
functionality, usability, robustness, scalability and cost savings as this Open Source solution. It is now 
being used in one of the largest and oldest services firms in the world. 

Requirements for a Secure Wireless Network Solution 

• No one is allowed to use our wireless networks without authentication and encryption at the network 
and or application layer. 

• We want to stick to a RFC standards based solution and avoid commercial lock-in, if at all possible. 

• We would like to make this solution as easy to use for the end user with very little user education 
required. 

• We also want to create a system that is not too onerous for the wireless network administrators to 
maintain. 

• All wireless networking must adhere to the same requirements that have been outlined for external 
perimeter networks. 

• All external network perimeters must be hardened and configured to protect against unauthorized 
traffic. All inbound and outbound points must be protected by means of a firewall and have an 
Intrusion Detection System (IDS) in place. 

• We should be able to track each user for any abuse and end their session and ban their account 
immediately, if need be. 

• We want fine grain control over what users can and cannot do, enforcing our security policy. We 
would like to be able to apply user specific rule sets. 

• We want Quality of Service (QoS) and bandwidth control. 
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The Quest for a Secure Wireless Network Solution 

Setting up a secure wireless network is not a trivial task. It involves a myriad of RFC standards, some 
dealing with authentication, encryption, key exchange, others dealing with wireless protocols, then there 
are firewalling concepts and security best practices and last but not least, we have to deal with actual real 
life users who constantly expose their machines. Fortunately, this solution is very inexpensive, user friendly 
and relatively easy to deploy. 

It is significantly more difficult to protect wireless networks than a traditional wired Local Area Network, 
LAN. Perhaps the most obvious difference is that wireless networks have a range that is generally defined 
within a circular perimeter often extending beyond the range of a traditional wired LAN (100 m). It is 
possible to triangulate the position of your users and rogue wireless hosts but if you are doing this, it 
generally means that you already have a problem such as an abuse, attack or breach of security. Tracking 
them down is non-trivial. The problem is further accentuated as you extend the range for your users; you 
do the same for the unauthorized users. Common sense would be to mitigate this problem from happening 
in the first place. 

The majority of our workforce use laptops running Windows XP SP2. Before setting up any wireless 
network, we did the utmost to ensure that the technology and solution employed was interoperable with 
our existing IT infrastructure and enforced the firm’s security policy. Data protection was paramount. 

One concern we had was implementing any solution that involved commercial lock-in. If this solution 
was to be deployed firm-wide, it didn’t make sense to lock other countries into any particular vendor’s 
proprietary hardware and/or software solution. In certain situations, it may be the only choice and in 
others it may be the best choice. However, if we do have a choice, we would prefer a solution that is 
based on an open standard with full documentation by which all vendors can compete for our business. If 
for some reason or another, we need or want to move to an alternative, we should not feel stuck due to 
investments in hardware, software or training. 

Cost was not as big a concern as much as ease of deployment and satisfying our firm’s Global Baseline 
Security Standards which meant that the Wireless Solution must at least have the following: 

1. strong authentication 

2. strong encryption 

3. firewall protection 

4. Intrusion Detection System 

All commercial solutions seemed to fall far short of the baseline requirements listed above. 

Furthermore, the commercial alternatives also meant lock-in of some sort with proprietary software 
and/or hardware, per node pricing and expensive modules in order to add more functionality. We then 
looked into the Open Source alternatives and found that the solution turned out to be surprisingly simple 
and practically free! OpenBSD [1] had everything that we were looking for: 

• A strong reputation and track record second to none in the area of security. It is a purpose built 
secure operating system. The OpenBSD Project Team has always maintained a proactive security 
stance [2,12,13]. 

• Strong Standards Compliance such as POSIX [12]. 

• Enterprise class firewall technology with very rich firewall functionality [3]. 

Packet Filter, Firewall Redundancy, Logging, Packet Normalization, Quality of Service, Load Bal¬ 
ancing, Authentication, IPv6 Support, NAT and more... 

• OpenBSD has integrated Cryptography. The OpenBSD Project started OpenSSH [5] which is the 
ssh implementation that is used by over 90% [6] of the Internet for secure remote access and admin¬ 
istration. 

• Open Source for transparent code auditing [2,7-10] 

• Free to use for any purpose with very few restrictions [4]. 
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The Secure Wireless Access Point (SWAP) 

The OpenBSD SWAPs that we use are disk-less and fan-free embedded devices [14] but they could be 
any hardware that is supported [16] by OpenBSD. These devices axe situated (wall or ceiling mounted) as 
close to the bulk of wireless clients as possible. They all run OpenBSD’s DHCP implementation that runs 
privilege revoked [12]. The connecting wireless clients are issued IP addresses, subnet mask, gateway and 
DNS information. 

The firewall is listening on tcp port 22 (for incoming ssh connections) using a privilege separated ssh 
daemon. No password authentication is allowed. The firewall will only accept ssh Protocol version 2 session 
connections from Windows clients using ssh keys only, i.e., any connection attempt from operating systems 
other than Windows such as Linux are dropped. For encryption, the SWAPs are also listening on udp ports 
500 (ISAKMP) [25] and 4500 (NAT-T) [22], The daemon, isakmpd, is also running privilege separated 
[ 12 ]- 

We have IPsec which provides encryption, authentication and integrity checking to protect all com¬ 
munication at the network layer. We use OpenSSH for encrypted dual factor authentication and if need 
be, encryption at the application layer. We have a firewall on the Access Point acting as a gatekeeper, 
so to speak, allowing or denying access to services and data on the internal LAN along with an Intrusion 
Detection System (IDS) in place monitoring all SWAP nodes. After this, users authenticate to internal 
resources as normal. 

The Wireless Clients 

The standard firm operating system is Windows XP SP2. Therefore, we are able to utilize Windows native 
IPsec support for the encryption. The only additional piece of software that we use is an OpenSSH port 
[17] for Windows (preferred for automation but requires installation and a reboot). PuTTY [18] can also 
be used but requires quite a lot of manual one-time configuration and some user training. Automation is 
lost when using PuTTY and therefore becomes a less user friendly solution leading to more help desk calls. 
However, both ssh clients are free and also Open Source. 

The clients are configured with OpenSSH for Windows and are issued 2048 bit ssh keys with a randomly 
generated strong passphrase for strong encrypted dual factor authentication to any SWAP. Encryption is 
automated through IPsec and Internet Security Association and Key Management Protocol (ISAKMP) 
using pre-shared secrets or certificates. All users will use an authenticating gateway user shell (authpf) 
from any SWAP within their office or building. If there are any user specific changes that need to be made, 
for example when a new ssh key is issued or if a user’s rule set has changed, replication to all SWAPs are 
done automatically via a shell script from any SWAP. 

There is a script that wireless clients use to automate both IPsec Security Association and ssh connection 
establishment. The script determines the IP address and default gateway issued by the SWAP that the 
user connected to in order to automatically initiate an IPsec session for encryption and then establish an 
ssh session for authentication. 

Other than the users executing this script, all they need to do is enter their ssh passphrase. Without 
encryption established and successful dual factor authentication, no traffic would be allowed to flow as per 
the firm’s security policy. 

Upon successful encryption and ssh authentication, their unique firewall rule set is loaded, the client 
receives an authenticating shell (authpf - no real shell is given) whereby the only command that they sire 
allowed to enter is <CTRL>+c which would then gracefully end their ssh session. At this point, we have 
fine grain control over what the user can do. We also apply Quality of Service and limit how much available 
bandwidth each user is allowed to use. When a user ends his/her ssh session, their rule set is unloaded and 
the IPsec Security Association (SA) and flows are subsequently flushed. If for whatever reason orphaned 
IPsec or ssh sessions are left dangling, they are automatically flushed with a cron job that r uns periodically. 

All authpf connections are logged to a central Log Server; therefore, we know who authenticated (Success 
and Failures), what IP address was used when they connected and for how long. The SWAPs also log all 
firewall traffic to the same central Log Server. An IDS is also be running on the same Log Server; however, 
this is not a requirement so long as there is an IDS in place monitoring each SWAP node. 


Problems and Solutions 

This solution was originally developed using PuTTY as it is a free Open Source ssh client. We think that 
it’s a wonderful little program that really filled a void. It’s small in size, less than 500KB and requires no 
installation. We still use PuTTY for the following situations: 
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• When guests need Internet access only. 

• If port forwarding applications through an ssh encrypted tunnel is sufficient. 

• If we do NOT have the luxury of installing OpenSSII for Windows on the laptop. 

• If we cannot install the native IPsec support from the Support Tools of SP2. 

However, where automation is needed and a desire to keep users from pushing buttons and messing up 
configuration settings, our preference is to use OpenSSH. 

Scalability was another issue that we found wanting in all the commercial solutions that we looked at. 
The main reason for this was the weakness or lack of authentication, encryption and firewall protection. 
Besides these deficiencies, we also wanted the users to be able to connect to any SWAP within their office 
or building. This is trivial when user authentication and encryption are not needed but raises the level 
of complexity when it becomes a requirement. OpenSSH and a simple script came to the rescue here. 
The script determines the user’s IP address and default gateway issued by the particular SWAP that the 
user connected to. This information is then automatically fed into a bat file that initiates the encryption 
and another bat file that establishes the authpf (ssh) session for authentication to the SWAP. Without 
OpenSSH [5], this kind of automation would not have been possible. Thus making this solution user 
friendly, scalable and very robust. 

We had experimented with ssh first then IPsec but this sequence was reversed and found to be more 
stable and easily automated. 

Physical security is always a concern. - The SWAPs are best positioned as close to the user base as 
possible which may not be the most secure place for an Access Point. Generally they will be situated 
on ceilings or wall mounted. We also want to have a way to access these SWAPs without having to use 
an attached keyboard or monitor. Luckily, the embedded devices that we use have relatively good serial 
console from which we can get access to the them if there is no network connectivity. 

Wireless authentication is usually weak if there is any at all. There are proprietary commercial authen¬ 
tication mechanisms but they often lock you into their proprietary software and/or hardware. This was 
remedied using strong dual factor ssh authentication using OpenSSH. 

Wireless encryption (WEP, WPA) are known to be very weak. A new standard (WPA2) is now available 
but depending on the vendor, you will find varying implementations on the standard [11], Using 3DES 
with IPsec was the solution to our encryption requirements along with Internet Key Exchange (IKE). 

Generic pre-shared secrets or certificates are needed as we will not know which SWAPs the wireless 
clients will be connecting to. This is a requirement for automation and scalability and therefore we do 
not rely on authentication using IPsec. Since we are using encrypted dual factor authentication using 
OpenSSH, this was an acceptable trade-off. Therefore, IPsec is only used for encryption at the network 
layer. To be clear, no traffic flows without successful authentication even with an IPsec tunnel up. 

Commercial Access Points generally do not have any firewall capability. OpenBSD’s in-kernel Packet 
Filter (pf) Firewall satisfied this requirement with more functionality than even the most sophisticated 
Commercial firewalls. For example, if you need IPv6 automatic failover functionality, then OpenBSD 
using pf is really your only choice and perhaps your best choice when compared to the alternatives. 

Limited bandwidth is a big problem for any wireless network. The quality of the network degrades 
as more wireless clients use the same Access Point. Fortunately, our solution does incorporate bandwidth 
control. We can configure the rules such that all users get only 5% of the available bandwidth and more if 
not used by others and IT administrators get a minimum of 15% of the available bandwidth. Alternatively, 
all users get a minimum of 128 Kbps or more only if available and IT administrators get at least 1 Mbps 
and more if available. 

The general rule for firewalls is to mitigate any risk of exploit by not running any services on the 
firewall itself if possible. Most commercial Access Points will be running DHCP, SNMP and Web Services 
for convenience, monitoring and administration. The only services running on our SWAPs are DHCP 
(privilege revoked), ISAKMP (privilege separated) and OpenSSH (privilege separated). 

Lastly, our experience working with many IT managers and IT administrators is that they have mis¬ 
understood the importance of wireless security and that it is not even on the same radar screen as that 
of an Internet Gateway Firewall. Access Points should be given the same due diligence as if they were 
Internet Gateways. There should be no distinction between the two. Education and awareness has helped 
considerably in this regard. 


Deployment 

The software, OpenSSH [17] and native Windows IPsec Support [21] is installed through various Software 
Installation Servers. The config files and user’s private key are copied to a designated directory on the 
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hard drive only accessible by the user. Normally this is done with a logon bat file using Active Directory. 
Newer configuration files and keys are also updated this way. The randomly generated passphrase is sent 
separately via an encrypted email to the user with a stern warning regarding abuse and/or misuse and 
instructions on how to use the Wireless Network. 


Limitations 

The maximum theoretical bandwidth for 802.11b is 11 Mbps. So you’re not going to get any more than 
this. In most situations it will vary between 4 6 Mbps depending on the distance away from the SWAP, the 
number of users on the wireless network and any other interference within the same spectrum. Support for 
802.llg (54Mbps) was added for OpenBSD 3.7 release. This release ships with many new wireless device 
drivers but their inclusion in the base system was late compared to other Operating Systems. “OpenBSD 
developers spent a considerable amount of time and effort to ensure that the software for these devices were 
free of any licensing restrictions. Many of these wireless chips are now supported with full documentation 
and used in all free Operating Systems thanks to vendors such as RALink, Realtek, ATmel and Zydas.” 
[28] 

This solution assumes a homogeneous environment and that you have control of your wireless clients 
running Windows 2000/XP. If you do not have Administrator privileges on the client laptops or if you do 
not have the luxury of installing OpenSSH for Windows and the native Windows encryption support, then 
obviously IPsec and automated authentication is not an option. The solution would then be limited to 
either application layer encryption using ssh whereby you would need to port forward applications through 
an encrypted ssh tunnel by using PuTTY as the ssh client. Port forwarding applications through ssh is 
not an uncommon solution but requires a lot of user intervention and helpdesk support. Even if you direct 
users to a PuTTY download page with clear instructions including screen shots and configuration details, 
this solution does not scale very well and your IT support staff may inevitably become the vent for user 
frustration and/or their inability to follow instructions properly. 

Windows 2000/XP does not support Advanced Encryption Standard, AES [23] which means the best 
we get in terms of encryption is 3DES [24], For alternatives, there is a great document [27] on OpenBSD 
and Road Warriors using encryption software such as PGPNet for Windows, and Linux using FreeS/WAN. 


The Future 

There is support for roaming wireless clients using hostapd [19] in OpenBSD but we have not yet im¬ 
plemented this yet. “There are exchange station association updates between SWAPs in large wireless 
networks. This speeds up roaming between different access points in the same Extended Service Set (ESS). 
IAPP is described in the IEEE 802.Ilf standard.” (29] What is interesting about this is the possibility of 
also sharing IPsec session state using SASYNCD [20] for a truly robust solution. Let it be noted that it is 
a work in progress. 

One way to avoid the problem of too many users connecting to any one particular SWAP is to turn off 
the SSID broadcast using a script that shuts off the SSID broadcast when the maximum number of users 
that are connected to the SWAP is reached. It is then turned back on when one or more users disconnects 
and we are below the limit that we have set for each SWAP. This is on our “To do list”. 


Conclusion 

Components such as encryption, authentication and firewall protection for this Open Source secure wireless 
network solution have been around for some time now. Unfortunately, papers on wireless network solutions 
using IPsec, authpf and pf were few and far between. Furthermore, most solutions that we found were either 
very expensive and did not satisfy all of our requirements such as strong encryption, strong authentication 
and firewall protection, or required lock-in of some sort (hardware and/or software) and just as important, 
most did not scale beyond one access point let alone thousands of users. The Open Source solution described 
in this paper has core security features that should be a part of every Corporate Wireless Network. More 
over, automation using, but not limited to, scripts is one of the key benefits to this solution making it 
scalable and very user friendly. There is no Lock-in as it is also not dependent on any vendors’ proprietary 
hardware and/or software but based on RFC standards and a free Open Source system and software that 
is known to have the best security track record bar none. 
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Abstract 

Beer is a well-known alcoholic drink, brewed in most countries in the world. It also represents one of 
the world’s most important chemical industries. This paper investigates the central importance of beer in 
modem civilization, suggesting even that it might have been the reason for mankind becoming sedentary in 
the first place. It continues with a description of the biochemical processes involved in making beer, and 
how computers can help. 

The foundations of civilization? 

Ancient man was nomadic. He hunted animals and ate plant matter such as roots and leaves, and when 
they were exhausted, he moved on. Starting about 7,000 years ago, that changed: in Mesopotamia, some 
groups of people stayed where they were. 

It doesn’t take much thought to realize that maybe the conditions there were so good that they didn’t 
need to move on: maybe there were enough animals, roots and leaves there to make moving on unnecessary. 
Certainly that played a role, but it would not have been enough by itself: the grass is always greener on 
the other side of the hill, especially for a nomad. 

Almost certainly, something developed that was so attractive that people didn’t want to move on. But 
what? Could it have been better food? Possible, but what could be so much better than what people 
already had? 

The obvious thing to do is to look at what people were eating at the time. Grass was high on the list. 
They didn’t eat the leaves, of course: they ate the seeds. The grasses were the ancestor of our modern 
grains, such as wheat, millet and barley. Like so many foodstuffs, they are seasonal. That’s an aspect that 
hasn’t completely changed to the present day, and 100 years ago much food was seasonal. You couldn’t 
get most vegetables for more than a few weeks per year. 

So what was special about grass? One thing was that the seeds were durable. They may only have 
matured over a few weeks per year, but they results would keep not only for the remainder of the year, but 
if needs be for several years. These issues are the background for the biblical story of how the Israelites 
came to Egypt. 

But grass wasn’t the only thing with durable fruit. Pulses (peas, beans and lentils) did so as well. Why 
didn’t they become a staple? They did in China, so there’s nothing intrinsic about them that rules them 
out. But it was grasses such as wheat and barley that became the staple food of most of Europe and Asia. 
Only where they weren’t available did people choose rice or pulses instead. 

We all learnt in school what grass (sorry, corn (sorry, grain)) is good for: making bread. And indeed 
ancient man made bread. If you’ve done this yourself, you’ll know it’s a non-trivial exercise: you have to 
knead the flour, add yeast, and wait for it to rise before sticking it into an oven. Ancient bread was simpler, 
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of course. They bypassed many of the problems with alternative techniques: instead of yeast, they used 
lactic acid cultures (“sourdough”), and instead of an oven they heated thin strips of dough on hot surfaces. 
People continue to do both of these to this day, and the relationship between the Hindi word nan and 
the Spanish word pan (both meaning bread) suggests that the techniques didn’t diverge until relatively 
recently. 

But there’s one thing that modern man doesn’t have to worry about when making bread: where does 
the flour come from? Even the word “flour” gives the lie: originally it was “Meal flower”, the finest milled 
meal from the grain. 

Grass seeds are not pleasant things to eat. They have a hard husk which even horses prefer not to eat. 
Inside there’s the kernel, but it’s pretty hard too (though it doesn’t worry horses). You can’t make bread 
out of either. 

Primitive man had to do for himself what nowadays specialized industries perform: 

• Harvest the grain. This involves going through the fields cutting off the seed-bearing parts of the 
plant. It’s not the worst, but it’s still a lot of work. 

• Next the seeds need to be separated from the stems. At the same time, the husks are separated from 
the kernels. This process is almost violent; the name thrashing gives an indication. 

• After this, and a bit of tidying up, you have the kernels. Wheat kernels look like little white bullets. 
Chew on them and you’re liable to damage your teeth (unless you’re a horse). You still don’t have 
anything useful to eat. 

Somehow the kernels needed to be made edible. Primitive man found at least two basically different 
ways to do so: 

• Use something hard, usually a stone, to crush them into smaller pieces. The best thing to say about 
that is that they didn’t break your teeth. 

• Soften them by boiling. This method is also still in use (porridge, gruel), but it’s not nearly as 
popular as milled flour. There’s no reason to believe that primitive man thought any differently: 
archaeologists report that primitive man spent a lot of time crushing grain. 

There must have been myriad experiments to find a middle way. An obvious one would be to soak the 
grain to soften it, then crush it. 

This method turns out to have side effects. The grain is a living organism, capable of growing to a new 
grass plant. It waits until it gets wet, then it germinates. In the process, enzymes transform the starch in 
the grain into the sugar needed for the growth of the plant. 

The result must have been that many such experiments ended up with a kind of germinated grain soup. 
It tastes sweet, so there’s a good chance that it was popular. But humans aren’t the only thing that like 
sugar: countless micro-organisms, notably lactic acid bacteria and yeast, live off sugar. In the process, they 
convert the sugar into other byproducts, such as lactic acid and ethanol. These transformations would not 
have stopped all humans from eating (or drinking) the results. And they would have noticed that, though 
it tasted sour, it made them feel good. Alcoholic drinks had been invented. 

Far-fetched? It’s supported by the linguistic evidence: the word brew and the word broth are related. 
Broth is derived from the old English word briw, meaning gruel (a dish of boiled grain). Both are derived 
from the Old Teutonic word *bru, as are the German (ge)brdu (brew) and brei (gruel). 

Archaeological evidence shows that man took the production of alcohol seriously from a very early time. 
But how seriously? 

Settling down 

Ancient man was nomadic. There were great advantages in being nomadic: it allowed man to be more 
flexible. Once settled down, man was at the mercy of local conditions. Such problems still occur: if there’s 
a drought, farmers have serious problems. Nomads could wander off and find something else to live off. 

So there must have been a corresponding advantage. Bread? It’s certainly more difficult to consume 
than other vegetables, but that in itself makes it unlikely that man would have given up his nomadic life for 
it. Beer, on the other hand, took time to make, and it offered something that was not readily available by 
other means. It’s very likely that this was one of the main reasons that man started to become sedentary. 
It’s interesting to note that, to this day, nomadic people do not make alcohol. 

Not everybody became sedentary at once, of course. Even within a tribe of nomads, it’s likely that 
some people settled down while others carried on their nomadic life. Recent excavations at the site of the 
ancient city of Caral in Peru (about 2000 BC) suggest that some of the first people to become sedentary 
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were the priests. They left behind ample evidence of use of intoxicants; it’s highly possible that beer was 
considered a holy drink, and the brewers were also the high priests. 

The conflict between beer and bread 

The fact that beer and bread are made from the same basic ingredient is an issue that still hasn’t been 
resolved. On 23 April 1516, Wilhelm IV and Ludwig X, dukes of Bavaria, proclaimed a decree at Ingolstadt 
which has since been called a “purity decree” (German “Reinheitsgebot”). In fact, the main purpose of 
the decree was different: 

• To ensure civil prices: 

Prom Michaelmas until the Feast of St George, one measure or ‘head’ of beer will not be sold for more than 
one Munich penny; and from the Feast of St George until Michaelmas, a measure will not be sold for more 
than two pennies of the same reckoning, and a head for no more than three heller, under pain of penalty. 

But when one brews any beer (other than Marzenbier), it will under no circumstances be poured or sold 
for more than one penny per measure. 

A “measure” (“MajS”) was 1.069 litres, a little less than an Imperial quart. A “head” (“ Kopf ”) was 
somewhat smaller, but there is no agreement on the exact size. 

• To ensure that wheat was kept for making bread, and that only barley (unsuited for breadmaking) 
was used for beer. 

Further we decree that henceforth in all our towns, marketplaces and the whole of the countryside, no beer 
shall contain or be brewed with more ingredients than barley, hops, and water. 

This is the text that is understood to decree the “purity” of the beer. While it certainly did limit the 
use of herbs and other bittering agents in beer, the important thing was that no wheat was allowed. 1 
Conveniently, for brewing barley is an easier grain to process than wheat. 

The process 

Making beer involves a surprisingly complicated series of biochemical reactions. At the very least it requires: 

• Allow the grain to germinate. This germination causes the release of enzymes required for the next 
step. 

• Crush the grain. 

• Warm the crushed grain in water to allow the enzymes to convert starch into sugar. 

• Cool the resultant liquid and allow to ferment. For any reasonable chance of success, yeast needs to 
be added at this point. 

By comparison, making wine requires, at the very minimum: 

• Place the grapes into a container which doesn’t leak too much. 

• Wait. As the grapes shrivel, the yeasts on the skin of the grapes will attack them and cause them to 
burst. It will then ferment the liquid. 

Obviously modern techniques are a little more refined, but even today most wines are made with the 
natural yeast from the grapes. 

The process: more details 

The method described in the previous section is the bare minimum. Except for experimental brews such 
as those described in [Anchor] and [Kirin], modern beers require more complicated versions of each step. 

1 Yes, wheat is allowed in German beers now, and it has been for a long time. But it’s prohibited by the “purity decree”, 
which hasn’t been the legal basis for German beer for a long time. That’s the “Vorlaufiges Biergesetz” (provisional beer law). 
But it makes nonsense of claims seen on beer bottles: for example, Schneider writes on the label of their “Aventinus” wheat 
beer, as sold in Australia: “Brewed according to the Reinheitsgebot”. 
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A quick sugar cheat sheet 

To follow this description, it helps to understand what sugars are. They include all substances commonly 
known as carbohydrates. The technical name is saccharide, and we can distinguish at least four types: 

• Monosaccharides are the simplest. They consist of rings of 6 carbon atoms with hydrogen and oxy¬ 
gen in the same proportion as in water (thus the name carbohydrate). Empirically, they all have 
the formula CeH^Og. Common examples are laevulose (also known by its old name of fructose) 
and dextrose (also known by its old name of glucose). Fruit juices, including grapes, contain laevu¬ 
lose. Another monosaccharide is lactose, which occurs in milk and which is of interest because it is 
unfermentable. It is used to make beers with a sweet aftertaste. 

• Next come the disaccharides, which consist of two monosaccharide molecules joined together. They 
all have the empirical formula C 12 H 22 O 11 . The most common one is saccharose, formerly called 
sucrose and commonly called sugar. For brewing purposes, maltose is more important. 

• A rare trisaccharide is maltotriose, which is formed during the brewing process. It is of no great 
importance. 

• The polysaccharides are what is normally called starch. It consists of a large number of molecules 
joined together in a random pattern. Typically it consists of branches containing straight chains of 
approximately 100 sugar molecules, depending on the origin of the starch. 

The process 

• Dry the grain. This may or may not improve the germination characteristics, but it makes it easier 
to handle. 

• Soak the grain in water for about a day, then drain. Barley is the most popular grain, followed by 
wheat. Occasionally other grains are used, such as rye and oats. The soaking causes the grain to 
germinate, and this germination causes the release of two enzymes, a-amylase and (3-amylase, which 
are required for the next step. 

• Dry the germinated grain in a kiln at temperatures between 40° and 100°. The process of germination 
and drying is called malting, and the resultant grain is called malt, independently of what kind of 
grain it is. Higher temperatures brown the malt, giving a richer flavour. 

• Next, the grain is mixed with a significant quantity of water, between 2 and 3 times its own weight, 
and warmed to temperatures between 30° and 78°. This process is called mashing, and the purpose 
is to convert starch into sugar. 

The mash is kept at specific temperatures for periods of time ranging between 10 and 90 minutes 
(so-called rests), enabling temperature-specific reactions to take place: 

— At temperatures between 30° and 45°, three changes take place: the pH (alkalinity) of the mash 
may lower (making it more acid), the grain soaks up moisture (doughing-in) , ostensibly making 
it easier for enzymes to react, and /3-glucanase can break down some gums. This rest is seldom 
used with modern malts. 

— At round 43°, ferulic acid is produced. With the correct yeast, this forms 4-Vinyl-Guajacol, 
which has a clove-like aroma much appreciated in Bavarian wheat beers. As a result, this rest 
is used for such beers. 

— The protein rest between 45° and 55° allows the enzyme protease to break down proteins. This 
can reduce haze in beer, but it also reduces the head, so it’s also not used much. 

— Between 55° and 65°, /3-amylase is active. It breaks down the straight parts of the starch into 
maltose. 

— Between 68° and 72°, a-amylase breaks down the branches in the starch, allowing remaining 
/3-amylase to convert it further into maltose. 

Typically 75% to 80% of the grain is converted into maltose. 

• After mashing, the resultant liquid, called wort, is separated from the remains of the malt. The 
English term for this is sparging, though the Americans also use the term lauter, derived from the 
German term lautem. 
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• Next, the wort is boiled and hops are added, a process that takes about an hour. The boil has a 
double purpose: to rid the wort of certain undesirable compounds, including proteins and methyl 
disulphide, and to isomerize the acids in the hops, bringing them into solution. 

• After boiling, the wort is cooled and aerated. The aeration is beneficial to the growth of the yeast in 
the next stage. 

• In the fermentation stage, the wort is pitched with yeast. This causes numerous reactions, notably 
the one that converts the sugars into ethanol (alcohol) and carbon dioxide. There are two basic 
types of yeast, which strongly influence both the progress of the fermentation and the nature of the 
resultant beer: 

— Top-fermenting yeasts form a scum on the surface of the wort during fermentation. Typical 
top-fermenting yeasts operate at 16° to 20° and complete fermentation in about 3 to 4 days. 
They are used for ales and wheat beers, and are the predominant British strain. 

— Bottom-fermenting yeasts do not form a scum. They also work at much lower temperatures, 
between 8° and 14°. Due to these lower temperatures, fermentation can take from 7 to 10 days. 
This style of yeast is used for lager and Pilsner beers, and is the predominant German strain. 

• After fermentation, the beer is stored for a certain period of time; bottom fermented beers are stored 
at a very low temperature, just above freezing, and they can take up to 3 months to be drinkable. 
All beers benefit from at least a month of storage, however. 


Technological aids to beer brewing 

Brewing has benefited greatly from technological improvements. Computers are no exception. There are 
two main areas where computers can help: in calculating the composition of a beer (and thus its character) 
and in temperature control. 

Composition calculations 

The following parameters are most important for determining the character of a beer: 

• Overall sugar content. This determines the amount of ethanol in a beer. Typical beers contain 
between 2 and 10% ethanol by volume. 

• Overall bitterness. The bitterness is determined by the quantity and nature of the hops, and the 
length of time for which they were boiled. 

• Colour. The colour is determined by the kinds of malt used. 

A number of other factors also determine the nature of the beer, but these are both the most important 
and the most easily quantifiable. 

A number of programs are available to calculate the ingredients for making a specific beer style. The 
best-known calculator is ProMash, a commercial program available for Microsoft “Windows”. It is also 
reported to run under Wine. It is the de-facto standard for brewing calculations, but from the point of 
view of this paper it has three disadvantages: 

• It doesn’t run natively on UNIX and Linux machines. 

• It uses American units by default. Even after a relatively painful configuration for metric units, the 
conversions show the underlying use of American units. 

• It costs money. 

A number of free programs are also available. None are as comprehensive as ProMash. 

• Qbrew [Qbrew] is a Qt application that offers much of the functionality of ProMash. Like ProMash, 
it has problems with metric units. 

• Brewsta [Brewsta] runs under python. It’s currently in beta test, and I haven’t been able to get it to 
work. 

• Brewnix [Brewnix] is a more mature package. I haven’t tried to use it. 

• brew (brew] is a collection of utilities that I have written and which I update as needed. They have 
the advantage of being command-line oriented and thus not requiring mouse usage, which proves to 
be difficult when your hands are wet or in flour. 
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Mash process control 

In addition to helping plan a beer, computers can help in the brewing process. The most obvious application 
is temperature control, which is important at different phases of the brew. 

The temperatures during the mash determine the characteristics of the beer. In the days before ther¬ 
mometers, there were two approaches to mash temperature control: 

• In the British tradition, it was largely a matter of mixing specific proportions of water at room 
temperatures and boiling water. For example, to mash at 64°, the strike water, the water added to 
the malt, should be at about 70°, depending on the relative amount of strike water and malt. This 
temperature can be achieved by adding one part of water at room temperature to two parts of cold 
water (about 10° in Britain). Old British mashes tended to be single infusion mashes, where the 
mash temperature was relatively constant over the duration of the mash. 

• In Germany and neighbouring countries, decoction was (and is) used. The mash process used in 
Pilsen in the early 20th century started by mixing the grist with the water and then removing a part 
of the mash, boiling it and then returning to the mash. By the choice of the quantity to decoct, 
multiple rests can be accommodated. 

Mash temperature control is complicated, and it’s an ideal application for computers. Unfortunately, to 
my knowledge no freely available software exists to perform the temperature control, though both ProMash 
and brew offer aids to calculate strike water temperature and decoction quantities. 


Fermentation temperature control 

As mentioned above, the temperature of fermentation is important for the quality of the final beer. Com¬ 
mercial breweries maintain the temperature of fermentation vessels with an ethylene glycol jacket around 
the fermentation vessels. Home brewers in Australia tend to use polypropylene fermenters with volumes 
between 20 and 33 litres, which are still relatively easy to move when full. They need some space for froth, 
so the typical batch in a 33 litre fermenter is between 20 and 25 litres. For some reason, the old “5 gallon” 
batch dies hard, and many choose a volume of 23 litres. 

For this kind of batch, a glycol jacket is both very expensive and probably inappropriate. I have never 
heard of one being made. The straightforward way to maintain temperature is to put the fermenter into a 
refrigerator. 

Under these circumstances, it’s relatively trivial to add a thermostat to maintain the temperature at 
the desired level. With the right choice of thermostat, it’s also possible to arrange to warm the fermenter 
when the outside temperature drops below the desired fermentation temperature, [old-control] describes a 
method using old fridge (which itself has a defective thermostat) with an off-the-shelf digital thermostat 
located on the lid of one of the fermenters. The thermostat is set to turn on the fridge compressor when the 
surrounding temperature is too high, and the lamp located beneath the fermenters when the surrounding 
temperature is too low. 

This approach is simple, cheap, straightforward and ineffective. The problems are: 

• The thermostat switches mains voltage, which is a safety hazard. To meet safety requirements, a 
couple of external relays and a low-voltage power supplies are needed. 

• The inside of the fridge can be humid. The thermostat is not suited to humid environments, but the 
temperature sensor is not removable, so it must be placed where the temperature is to be measured. 
Further experiments showed that the humidity problem could be combatted by placing the thermostat 
in a thin plastic bag. 

• The thermostat is a simple switch-over model: one of the contacts is always closed. This means that 
the device is always either heating or cooling. In practice, it’s possible to disconnect the output to 
the cooler or heater, but this results in less accuracy when the outside temperature is close to the set 
temperature. 

• The temperature is measured in the wrong place. The temperature on the lid of the fermenter is 
of only marginal interest. Fermentation generates heat, and so the wort temperature will be higher 
than the surroundings, as much as 6° higher than the set temperature. This is inadequate for the 
purpose. 
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The temperature problem is even more complicated than it looks. The fermenter is only cooled from 
the outside, so the temperature in the middle will be higher than on the outside. Where is the correct 
place to measure the temperature? 

There are obvious places to measure the temperature: the surface of the fermenter and the middle of 
the wort. The former will measure too low a temperature, and the latter one too high a temperature. A 
compromise would be to put the sensor about halfway between the axis of the cylinder and the surface, 
which comes closer to an “average” temperature. 

Measurements inside the wort have two basic problems: 

1. Obviously the cables need to be encapsulated in something to protect them from the wort, and even 
so it’s difficult to maintain good sanitary conditions with cables stuck into the wort. 

2. The wort reacts very slowly to external temperature changes; a step change of 10°, typical when 
refrigerating, can take hours to become noticeable. This gives rise to the danger of overcooling, 
followed by overheating. 

Placing the sensor on the surface of the fermenter has neither of these problems. It’s true that during 
cooling and heating it results in a slight offset from the wort temperature, but this is not a problem once 
the wort has reached a steady state. 

A usable solution would thus measure the temperature of the outside surface of the fermenter and 
control a heater or cooler, with some temperature tolerance during which the device neither heats nor 
cools; ideally the system would spend most of its time in this condition. [Sorenson] describes such a device 
based on purely mechanical components. The web page does not describe the accuracy of the temperature 
control, but it’s reasonable to assume that it’s adequate. 

The problem with Sorenson’s approach is the components. As the article describes, they are no longer 
available. It is also not suited for more complicated procedures, such as slow, constant temperature changes 
such as are used after primary fermentation: bottom fermenting beers frequently need a diacetyl rest, a 
raise of temperatures to about 16° (see below for an example), and top fermenting beers benefit from a 
cooler secondary fermentation. In each case, a step change in temperature is not desirable. 

Based on this background, I created a more flexible solution, based on an little-used Intel 80486 computer 
with a relay board and a digital thermometer input. 

Overview 

The control system uses a computer to monitor a number of temperatures inside a fridge and turn on either 
the fridge motor to cool the surroundings, or a light bulb to warm them: 

The equipment I used is: 

• An old computer, of course. The size of the one I chose is simple: that’s what I had lying around. 
It’s an Intel 486-DX2/66 with 16 MB of RAM, something you can probably pick up for free if you 
know where to look. It’s running FreeBSD (http://www.FreeBSD.org/), of course. 

• A temperature logger kit (http://ozitronics.eom/kitlist.html#kl45) available from from Oz- 
itronics kits (http://ozitronics.com/). It connects to the system via the serial port. 

• A relay board (http://ozitronics.eom/kitlist.html#k74) also available from from Ozitronics 
kits (http://ozitronics.com/). It connects to the parallel port and controls up to 8 relays with 
up to 250 VAC and 10A, though they recommend additional wiring for currents of over 5A. A fridge 
typically uses a maximum of 3A, so this is of academic interest only. 

The real fun in getting this working wasn’t the hardware, which is easy enough to get. It’s also not 
really the software, which I wrote myself, and which I’m still tweaking. The real problem were the little 
details and connectors and things. I spent a lot of time trying to decide how to connect things. Finally I 
discovered an old computer lying around without a mother board, so all the front panel connectors were 
hanging loose. That’s exactly what I was looking for to mount the temperature sensors: 

Other issues in the mounting included the fact that the kits are designed for external mounting (and the 
relay board needs a 12V power supply). I wanted to mount both inside, which had the added advantage 
that I could use the computer power supply to power the relay board. The problem was a certain amount 
of external cabling: 

This one shows the temperature probe assembly. There are no mounting holes on the probe board, 
so I had to mount it by its 9 pin serial connector. I had already connected to probe cables to a 25 pin 
connector. I wanted it inside the case, so I had to connect the flat cable to the serial port on the outside 
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of the case (the grey cable going out through another cutout just below the probe board). I need to find 
some kind of plate that I can use to mount it inside the case. 

A view of the back of the computer. This shows a number of things: 

• The lower cable goes from the parallel port back inside to the relays. It would be nice to have internal 
cabling, but I don’t know of any parallel ports that connect to a header on the board. They’re all 
connected directly to an external connector. 

• Above that is the temperature probe cable, as shown before. 

• Higher and to the right, the flat band cable mentioned previously. 

• At the top are the relay power outputs (white) and the computer power cable (black). The power 
supply is in at an angle because it was originally designed for a smaller case, and the internal cables 
are too short to allow normal mounting. It has since been replaced. 


Installation 

The next step was installation in the laundry: 

The temperature sensors can be seen in the enlargement on the web site. 

• The external (“room”) sensor is on the outside left of the fridge. 

• The internal (“ambient”) temperature sensor is in front of the 25 pin connector. It’s fastened to one 
of the bars of the grille. 

• The wort temperature sensor is taped to the outside of the fermenter. It’s covered with some bubble 
foil to minimize the effects of the ambient air. 

• The fourth sensor is for a second fermenter. In this image it’s unused and hanging down in front of 
the light. 





THE SOFTWARE 


201 



Figure 1: temperature sensors 


The software 

The software reads its parameters from a configuration file which can define a large number of parameters. 
Almost all of them have defaults. The most important parameter to change is the fermentation temperature. 
Two temperature parameters are provided to handle temperature ramps: 

• starttemp is the temperature to set when the program starts. If the temperature is to be constant, 
this is all that needs to be set. 

• endtemp gives both a temperature and a time for the end of the ramp. For example, to start at 19° 
and drop to 14°, the file might contain: 

starttemp 19 

endtemp 15 15 September 2005 0:0 

This would start out at 19° and progressively cool to 15° by midnight between 15 and 16 September. 
This choice of parameter is an inadequate approach to the issue of maintaining the ramp even if the 
program is stopped and restarted during the ramp. More effort needs to be addressed to this issue. 


Cooling and heating 

The simplistic approach to temperature control is shown by the digital thermostat described above: if it’s 
too cool, heat. If it’s too warm, cool. This is clearly inadequate. At the very least, the system needs 
to accept a minimum range in which it will neither heat nor cool. Without such a range, it would be 
continually either heating or cooling. 

In fact, there are a number of issues here: 

• If the idle temperature range is too wide, the accuracy of temperature control suffers. 

• If the idle temperature range is too narrow, the system can end up alternating between heating and 
cooling. This, too, diminishes the accuracy of the temperature control. 



202 


FREE AS IN FREE BEER 



Figure 2: external cabling 


• If the cooler is turned on or off too frequently, it can cause damage to the system. Typical refrigeration 
units have safeguards to ensure that they don’t turn on or off more than about every 60 to 300 seconds. 

• When the heater or cooler turn off, the air temperature differential ensures that the fermenter surface 
continues to increase or decrease in temperature: it overshoots the mark. 

The temperature control system attempts to address these issues, with varying degrees of success: 

• The original intention was to keep the temperature within 0.5° of the goal temperature. As controlled 
by the PIC, the sensors have a resolution of approximately 0.07°, so this seemed reasonable. In fact, 
it has proven to be possible to maintain the temperature to within 0.10° of the goal temperature, a 
very satisfactory result. 

• The program should learn from its mistakes and compensate. For example, it should learn to what 
extent the temperature overshoots, and how long it takes to recover, and choose its parameters 
accordingly. This aspect is still not satisfactory, and in the meantime a number of tuning parameters 
are available to tune the system. 


Sample output 

The software produces output in a number of formats: 

• It outputs temperature statistics approximately once per second onto the controlling tty: 
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Figure 3: This one shows the relay board with the mains power connections. 

Time Brew Probe Base Ambient Goal Offset Room 

61 2 

14:49:41 18.31 15.25 18.31 15.68 18.21 0.10 17.87 

Status: Cooling 

In this example, only one of the two probes is being used to actively control the temperature. The 
information is: 

Brew 61 is a label specified in the configuration file to help identify the brew: 

fermenterllabel Brew-61 
fermenterllabell Brew 
fermenterllabel2 61 
fermenter21abel Probe 2 
fermenter21abell Probe 
fermenter21abel2 2 


Probe 2 is the other temperature probe. In this example, it is not connected to anything. It is still 
functional, so it shows a value roughly corresponding to the ambient temperature probe. The 
difference between the two is not an issue of the accuracy of the measurement: it shows the 
natural temperature differences in different places in the fridge. 

Base is the calculated base temperature that is being controlled. It is somewhere between the 
temperature of each of the two fermentation temperature probes. In this case, since only one 
brew is being made, it is set to be identical to the temperature of brew 61: 

probe2factor 0 

probe2factor is a (floating point) value between 0 and 1 which specifies the extent to which 
the temperature of probe 2 contributes to the calculation of base. The formula is: 

basetemp = temps [fermenterprobe] * (1 - probe2factor) 

+ temps [fermenter2probe] * probe2factor; 
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Figure 4: A view of the back of the computer 


Ambient is the air temperature inside the fridge. 

Offset is the difference in temperature between the Goal and Base temperatures. 

Room is the temperature outside the fridge. 

The bottom line shows the current status; it is cooling the wort to bring the temperature down from 
18.31° to the current goal of 18.21°. 

• This representation is also available across the Internet with the command 

$ telnet brewer.lemis.com 4135 
Trying 192.109.197.147... 

Connected to brewer.lemis.com. 

Escape character is ’ 

Time Brew Brew Base Ambient Goal Offset Room 

43 44 

18:23:39 19.06 18.93 18.99 18.12 19.00 -0.01 23.31 
Status: Idle 

Connection closed by foreign host. 


• The other representation is a graph. A recent graph (typically less than a day old) is shown on my 
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Hgure 5: Installation 


brewing home page (http://www.lemis.com/grog/brewing/). A typical graph looks like this: 2 


Brew temperature 


Brew 48 • 
Brew 49 
ambient (raw) 
ambient (smoothed) • 
goal 
room 
heater 


09/02 10/02 11/02 12/02 13/02 14/02 15/02 16/02 17/02 18/02 19/02 20/02 21/02 

00:00 00:00 00:00 00:00 00:00 00:00 CJttjOp 00:00 00:00 00:00 00:00 00:00 00:00 


1. Y axis: temperature. 

2 Note that the conference proceedings are printed in black and white, which makes it very difficult to read this example 
Colour versions are available in the slides and the original of this paper; see the bibliography for details. 
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2. X axis: Time and date. 

3. Red line: temperature of first brew (Brew 48 in the example). It starts off at nearly 25° and 
quickly drops to 20°. After about a day it gradually rises to about 21°, and takes about 2 days 
to return to the set temperature. 

4. Green line: temperature of second brew (Brew 49 in the example). It starts off a little later than 
brew 48 at about 23°, and also quickly drops to the set temperature. At the same time that the 
temperature of brew 48 rises to 21°, it performs a complementary drop to about 19°. This is 
one of the drawbacks of the system: brew 48 is fermenting vigorously and generating significant 
warmth. At this point, brew 49 is not fermenting as vigorously. Since the heating or cooling is 
only by the ambient air, it is not possible to get exact temperature control for both brews. The 
system controls the base temperature, not shown on this graph, which remains close to 20°. 

5. Dark blue line: ambient temperature in the fridge. This is the temperature of the air that 
cools or warms the beer. Initially it drops sharply to about 3° to cool the beer down to the set 
temperature; then it shows a very jagged curve as the cooler cuts in and out. 

6. Purple line: a smoothed version of the ambient temperture. The jagged nature of the ambient 
temperature curve makes it difficult to see the average. 

It’s worth noting that throughout the fermentation, the ambient temperature is lower than the 
wort temperature, due to the need to remove the heat of fermentation. 

7. Cyan line: goal, the temperature that the wort should achieve. In this case, it’s a constant 20° 
throughout the 12 day fermentation time. 

8. Brown line: room: The temperature outside the fridge. This is purely informational; it (cur¬ 
rently) isn’t processed in any way. As can be seen, it has almost no effect on the ambient 
temperature or wort temperatures. 

9. Yellow line: indicates whether the system heats (line up from centre) or cools (line down from 
centre). There is a certain correlation here with the outside temperature, of course. 

I have been experimenting with a further line showing the smoothed rate of heating or cooling, 
but this has not been completely satisfactory. Some of the other graphs show the effects. 

The following graph shows the first five hours of two fermentations in more detail, from the time the 
system is started until shortly after the second brew is placed into the fridge: 


Brew temperature 



Time 


At about 2:45 (UTC in this example) the system is turned on. The sensors are not connected, so 
the system sets the temperature to 20°. In this state temperature control is poor, since there is little 
thermal mass to stabilize the temperature. 










SAMPLE OUTPUT 


207 


• At about 3:55 UTC, the first brew (52) is placed in the fridge at a temperature of about 23°. The 
system immediately starts cooling and continues until about 4:35, by which time the outer surface of 
the fermenter has reached 20°. At this point the ambient temperature is about 6°. 

• The wort is still warmer, and to maintain the outside temperature the system has to continue to cool 
at regular intervals, gradually raising the ambient temperature. 

• At 6:15 UTC, the door of the fridge is opened, causing a sharp rise in the ambient temperature. The 
cooler turns on again and cools back to the necessary ambient temperature. 

In this example, the temperature of brew 52 also goes up by about 1°. This is indicative of a poor 
contact between the sensor and the fermenter: the ambient temperature influences the reading more 
than it should. 

• Finally, at about 7:00 UTC, the second fermenter is placed in the fridge and connected. Again the 
ambient temperature and the temperature of brew 52 rise, but more notably the temperature sensor 
for brew 53 (green line), which previously has been tracking the ambient temperature, rises as well. 
Again the system cools back to the set temperature. 

It’s worth noting here that during this time the base temperature should be set to the temperature 
of the first fermenter (probe2factor set to 0), so that the low reading for the second temperature sensor 
doesn’t influence the temperature. After adding the second fermenter, it should be set to 0.5. 

The next graph shows a more complicated set of temperature transitions: 


30 


25 


20 


rc 

$ 

Q. 

| 

10 


5 


0 
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This graph shows the brewing of a bottom-fermenting beer. Fermentation starts at 14°, but as soon 
as it is under way, the temperature is lowered first to 12°, then to 11° and finally 10° for the bulk of the 
fermentation. After two weeks, the temperature is ramped to 18° for a diacetyl rest, then dropped again 
to 14° until bottling. 

This graph also shows a weakness of the system: between 19 June and 27 June, the heater turned on 
several times to compensate for overcooling. It’s possible to get rid of this problem by lengthening the 
hold-off time between turning the cooler off and turning the heater on, but ideally the system should learn 
this itself and not require external intervention. 


Brew temperature 
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Current status 

The first version of the software had the typical “open source” disease: the documentation is pretty 
primitive. Since release I’ve found some minor bugs which I have mainly fixed. When the remaining bugs 
are fixed, I’ll write some proper documentation. 


Experience with the system 

The system has now been in use for about 14 months. It has done its job well, and the accuracy of 
the temperature has surpassed all expectations. It normally maintains the temperature to within 0.1°, 
a surprisingly good result considering that the resolution of the sensors is about 0.07°. There have been 
some issues, however: 

• The connections to the temperature sensors have been less than ideal. The choice of connectors is 
not well-suited to the environment, and the connections can corrode. 

• The PIC microcontroller does not handle misbehaving sensors well, and can send nonsensical values 
to the computer. 

I have upgraded the software to ignore obviously invalid data records from the PIC microcontroller, 
but it is still possible to get valid-looking data records that are just incorrect. Some heuristics may 
help here, but so will an alternative solution: the temperature sensors can be connected directly to a 
serial bus, and with some level transformation logic and a modified serial line driver, a theoretically 
infinite number can be handled by the main compuer puter. In this case, more sophisticated error 
handling should be possible. 

• Attaching the temperature sensors to the fermenter is more complicated than it looks: the accuracy 
of the temperature control depends very much on the good contact between the sensor and the surface 
of the fermenter. If there is even a small gap, the accuracy of the control diminishes greatly, as shown 
in the second graph. 

• Currently the software runs as a single process and thread. The log files are NFS mounted, so if there 
is a network problem, the entire process can hang. I intend to handle this problem in two ways: 

1. Use a separate thread to handle output where needed. 

2. Migrate to a system where the remote computer requests information. This is partially provided 
by the TCP connection, but it is obviously too much overhead to set up a new connection on 
every enquiry (which typically is once a second). I’m planning a UDP alternative. 


Future directions 

There’s still plenty of work to do on the project, which I’ll do when the itch gets strong enough. Obvious 
ones are: 

• Write proper documentation. 

• The system isn’t protected against power failures (there’s not much point, given that fridges aren’t 
either). But if it fails during a temperature ramp operation, there’s no way for the system to know 
what temperature to set when it restarts. Saving information to disk should help there. 

• Modify the system to cool multiple fridges. Even the base hardware can handle four temperature 
sensors, enough for two fridges with one fermenter in each, and the relay board has eight relays, 
enough for four fridges. With an additional temperature sensor board, it could easily control three 
fridges. The real issue is in the program structure: how to define the parameters for each fridge, and 
how to keep track of them? That’s a soluble problem. 

• The system does not do a very good job of learning when to turn the power on and off. This issue 
requires further consideration. 

• As mentioned above, a UDP interface would make it easier to perform repetitive queries. 

• The current system only addresses fermentation temperature control. As mentioned, it would also 
be desirable to have a system for controlling mash temperature. Plans are under way to do this. 
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• Beer is not the only thing that can benefit from temperature control. Australian domestic ducted air 
conditioning systems have appallingly bad temperature control; a modification of this program could 
handle that as well. Many other such applications exist. 
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Confession Time: Deadly Sins Using 
MySQL and PHP 

Arjen Lentz 

Community Relations Manager, 

MySQL AB 
arjentSmysql. com 

Since my talk this year graciously scheduled as a plenary session by the AUUG program committee 
is mostly in quiz format and I don’t want to spoil the fun by providing the answers here, I thought that 
instead I’d write a bit about the underlying reasons for talking about these “deadly sins”. Or perhaps I 
should say causes. People do a lot of what I would call ‘evil’ things when designing their database tables, 
phrasing their queries, and coding their applications. 

I just use PHP for the examples in my talk because its syntax is easy to understand even for those 
who are only familiar with other programming or scripting languages, and the issues I discuss are by 
no means limited to PIIP. Although, it is often noted that PHP, through its very relaxed syntax (loose 
typing, automatic casting) actually encourages bad behaviour, whereas Java, for instance, enforces ‘ good ’ 
behaviour. I can go along with that basic assessment, but I would add that PHP (together with MySQL) 
has also played an important role in the use of dynamic web sites. The relaxed syntax is undoubtedly part 
of why it is easily picked up by people, many of whom have little or no experience with programming. And 
that’s what this story is about. 

I will fess up, I have no formal education in programming myself. But my experience dates back to 
the early 80s, when you just had do your own programming to make your computer do anything useful. 
To make things work, you also had to know how (and why) things function the way they do inside the 
computer. And that helps. These days, it appears that with people using ready-made components and re¬ 
using existing snippets of code, they have no understanding of what’s really going on. As a funny example, 
one of my training colleagues actually needed to clarify to a student that scripts are processed from the 
top down. It may be self-evident to you and me, but for someone without any “old style” computing 
background, it apparently wasn’t. 

I think that fundamentally, good programming is not magic. It’s just basic logic, or common sense. 
In any case, skills that I would hope people pick up either at home or in school, early on. I don’t believe 
that in order to do proper programming, one needs to have detailed knowledge of information systems 
theory, or that, in order to use an SQL RDBMS effectively, a full education in relational theory is required. 
There’s no need to go all academic. In my opinion, what’s needed is a clear explanation from knowledgeable 
people about the essential fundamentals of a topic. Not all underlying concepts need to be discussed, but a 
practical subset that provides a person with sufficient understanding of the why and how. This will allow 
people to apply their new skills, in a sensible manner, to a variety of related problems. They will be able 
to identify these problems as similar to cases they already know. 

I don’t like many of the tutorials that are available on the net, or in books. Possibly for reasons of 
brevity and simplicity, they often do not cover any of the fundamentals mentioned above, but instead go 
for a simple “monkey see, monkey do” kind of approach: “when you type this and this, out comes this.” 
That’s great, but do you have any idea what you’re doing? You might, but not necessarily. The method 
certainly does not enforce or even encourage it. It basically trains, well, monkeys! Do we really want that, 
even for the noble reason of making programming accessible to the masses? I doubt it. And really, I don’t 
see my opinion as an attempt to exclude the masses. What I’m trying to promote is a sensible and suitable 
education for these same people, whom I’m pretty certain are not monkeys and therefore should not be 
trained as such. 

One challenge now is that people have become used to this type of over-simplistic tutorial-based ‘edu¬ 
cation’. Often, when I tell a user on IRC that understanding joins would be really handy when using SQL 
(and introduce the relevant concepts along the way), they get really cranky with me and accuse me of not 
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really wanting to help them resolve their problem. They simply want me to either tell them exactly to do 
what they asked about, or point to ... you guessed it... a tutorial! In a way these people are absolutely 
right about my resistance, but the reason is the important bit: I would rather not assist someone to dig a 
hole that they’d fall in to shortly after. 

Sure, I could write this one query for them, a small effort. Running off happily, they would then bump 
into the next (related) problem only a few minutes later and still be none the wiser. So they’d need to ask 
again. What’s the point? You can show a person how to use a saw, a drill, and a screwdriver, but that 
does not mean they can build a house! There’s slightly more to it than that, even though fundamentally 
one can build the structure of a house with those tools. Basically, I’d be doing their work. That while it 
may be a fun exercise at times makes no sense to me. If you want to learn, really learn. 

Cut&Paster : u But I don’t care how it works! 

I just want to do this one web page thingyV 

Response : “Yes, well... isn’t that somewhere between lazy and rude?” 

Why rude? The definition of a hobby is spending your free time in a way that’s interesting to you. 
That is, your own free time not someone else’s! Of course there are people willing to help, but the hobby 
can’t be other people doing everything. Let’s not become too lazy. 

When I write an article or teach a training course, I always try to not just teach facts, but to help and 
develop skills. Many of you who read this article are yourselves also authors or teachers. Let’s agree to 
not take the simplest road, and to try and work towards explaining elaborate technologies in manageable 
chunks. I think it is possible to find a reasonable middle ground that really helps people develop their 
skills and do the things they want to do, easier and better. 

Now let’s looks a bit more at a couple of the skills that I would like to see budding programmers develop. 

Scenario 1 

In a script that calls database functions, a query does not work: no results are displayed. You ask 
the programmer if they’ve checked for errors. Sure, the script processor reports no errors. Hmm... 
with me, that already triggers a mental alarm. One aspect here is understanding the fact that only 
language syntax errors are caught. The script processor doesn’t care if you mess up a query, in terms 
of language syntax everything can be perfectly correct. But the script should check the results of any 
database function call for errors, and report back not just that there was an error, but specifically 
which one. You don’t want to make it into a guessing game. Error messages from the database server 
often provide plenty of relevant detail, once you learn how to read them. 

Code examples generally don not include error checks, because their handling is application specific 
and makes the example overly complicated. But it’s essential to appreciate that you can’t just cut &, 
paste a piece of code without also applying your own intelligence to the situation. It’s fine to re-use 
code, but you don’t want to behave like a silly monkey. It’d be painful. 

Scenario 2 

When developing a little test application, you just use the root or administrator account to connect 
to your database server. It’s easy, you have all the privileges you need and there’s no need to fuss 
with setting up special users. Sure! 

The problem is, I’ve seen production systems on the public Internet doing this, too. Imagine what 
can happen if the application happens to be vulnerable to an SQL injection attack! The business can 
effectively be shut down, users’ private data can be compromised or stolen, and much more. While 
we could debate the actual correlation between the described test application and the production 
system I’ve seen, I think we can agree that if people simply never set up a test system in this way, it 
can never end up on a live public system either. 

So what is the root problem here? (no pun intended!) I think that this actually teaches us about 
sensible good habits, a topic that is not even specific to computing. If you always practise these good 
habits, they quickly become second nature and stop requiring any extra time. The challenge lies in 
overcoming your own inertia: the initial extra effort required to develop the good habit. It is said 
that human habits become entrenched in about 3 months. That’s not so long, is it... you might as 
well make it a good habit rather than another bad one! 

It also teaches that something that appeared to be a nifty idea (in terms of saving time on the 
one particular occasion) actually comes back to cause trouble later. That kind of behaviour is 
unfortunately nearly endemic. You can hear about such short-sightedness and its consequences on 
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the news, almost on a daily basis. There are really plenty of programmers around, why would you 
want to be one among the big crowd... stick out through providing real quality. 

Are any of these ‘sins’ actually deadly ? That’s the point: each on their own they can be fairly 
harmless. But they rarely come alone. How many inter-related stuff-ups does it take to create a real 
disaster? I would say that each actually does have potential to be deadly. 

In my talk, I will cover many more little issues. But it’s explicitly not my intention to bore you 
by documenting every single instance. Instead, these examples are merely intended to, while having 
some fun, get you thinking about it. Once aware, you’ll be able to spot potential problems early and 
use the appropriate techniques to prevent them. 

And so we may conclude that this year in my AUUG talk I will be discussing monkeys. Last year was 
about elephants and that turned out to be quite popular. What animal will be next year’s subject, I 
wonder! But first, this year. I’m sure that at least some of what I described in this article will sound 
quite familiar to you. We all engage in monkey-like behaviour at times. So why not just confess to 
one or more of the many bad habits, laugh about our own nave silliness from back when we thought 
they were actually good ideas, and learn at the same time! 
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Abstract 

An overview of the MySQL Cluster architecture, what’s different about it and what problems it can be used 
to solve. We’ll be looking at how High Availability is achieved as well as setup considerations regarding 
performance. Basic use will also be covered, from setup (including schema considerations) to new (and 
exciting!) features for the 5.0 and 5.1 releases. 

Introduction 

MySQL Cluster is a fault tolerant in-memory clustered database designed for 99.999% availability and fast 
automatic fail over all running on cost effective commodity hardware. 

MySQL is an open source ACID 1 compliant Relational Data Base Management System (RDBMS) aim¬ 
ing towards full SQL standards compliance. It has a reputation for ease of use, speed, quality and reliability 
and consequently is the worlds’ most popular open source database with over six million installations. 

At time of writing (July 2005) 5.0 is in beta and 4.1 is the stable release. By publication, 5.0 should 
have moved out of beta and at least one alpha release of 5.1 should be available. MySQL Cluster has been 
included since 4.1.3 and in RPMs since 4.1.10a 2 . It is included as part of the MySQL-Max distribution 3 . 
We officially support MySQL Cluster on Linux, MacOS X and Solaris. Users have reported success with 
FreeBSD. We plan to support all MySQL platforms in the future. 

The NDB Storage Engine 

Storage engines are a unique architectural feature of MySQL. The VFS layer of your operating system 
allows applications to access files on different file systems through the one interface, MySQLs’ storage 
engine architecture allows applications to access data stored in different ways all through the same SQL 
interface. Two commonly used storage engines are MylSAM (speed, full text indexes, GIS) and InnoDB 
(row level locking, multi-version concurrency, ACID). 

MySQL Cluster provides a new storage engine for MySQL. The NDB (also known as ndbcluster) 
storage engine provides high availability in a shared-nothing architecture. Since there is no shared or 
special hardware (such as a SAN), MySQL cluster can easily be implemented on affordable commodity 
hardware. All data is synchronously replicated between nodes. The NoOfReplicas configuration parameter 
dictates how many copies of the data are kept in the cluster. 

In the 4.1 and 5.0 releases, all data must be held in main memory on the nodes. A rough estimate of 
the memory needed in each node is 5la ° ,fCa ^^.Q^* 1 ' 1 . A transaction is committed when 
it is in memory of more than one node (i.e. it can survive a node crash). The in-memory architecture has 
the advantage of being very fast, with a single CPU able to managing over 10,000 transactions per second. 

Persistence is provided by periodically writing checkpoints to disk. The timing between checkpoints 
(among other things) is configurable. It is also possible to perform online backups of data in the cluster. 

1 Atomicity Consistency Isolation Durability 

2 There are separate cluster RPMs that need to be installed 

3 This is different to the MaxDB product - which is a separate RDBMS by MySQL AB 
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After a system failure (where enough nodes have failed that the cluster no longer has a full data set) the 
system is restored to the last global checkpoint. When a single node is being restarted (node recovery) it 
will fetch the latest data from another node in the cluster. 

The 5.1 release will allow non-indexed fields to be stored on disk. In the future, it will be configurable 
if you want a disk or main memory based cluster. In current releases you can also run in Diskless mode, 
where no data is ever written to disk (no checkpointing, no logging). 


Components of a Cluster 

Figure 1 shows how an example cluster may look. 



Figure 1: Example Cluster 


Applications 

Applications connect to the cluster via a MySQL server exactly the same way as they would if they were 
using any other MySQL storage engine. Using the cluster is transparent to the end application. 

It is up to the connector or application to load balance between the MySQL nodes. Some people use 
load balancing products, others use features of the connector (e.g. the MySQL JDBC driver) and others 
write their own small snippets of code to load balance and fail over. 

In the event of node failure, all transactions that were using that node are aborted and it is up to the 
application to restart them. 

MySQL Server nodes (mysqld) 

Multiple MySQL servers can connect to the one cluster. This provides redundancy and increased perfor¬ 
mance due to parallelism. When an update is performed on one MySQL server it is immediately viewable 
from other MySQL servers attached to the cluster. 

Data Nodes (ndbd) 

All data is stored by the data nodes. This data is visible to all the MySQL servers connected to the cluster. 
Some MySQL special data such as the permissions and stored procedures are not stored in the cluster and 
must be updated on each MySQL server attached to the cluster. 
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Management Server Nodes (ndb_mgmd) 

The management server provides configuration information to nodes joining the cluster. It is not a critical 
part of the cluster, only needing to be up for a node to join the cluster. 


Management Client (ndb_mgm) 

An end-user tool for administering and checking the status of the cluster. This can be used for starting 
and stopping nodes, getting status information and starting backups. 


Node Interconnects 

MySQL cluster supports several methods of transferring messages between the nodes. The most common 
is the TCP Transporter over 100Mbit or 1Gbit Ethernet. There can be significant performance gains in 
using gigabit Ethernet. You can also use SCI, which is a high-performance, low latency interconnect. There 
is also a shared memory transporter for nodes running on the same host, although it should currently be 
considered experimental. 

Since communications between nodes are unencrypted, it is recommended to have a private network 
exclusively for cluster traffic. This also ensures that no other systems interfere with the performance of 
the cluster. 


Sample Configuration 


Figure 2 shows additions to the my.cnf file for connecting to a cluster. The connect string tells processes 
where management servers are so that they can join the cluster. In this case, we have one management 
server, so the connect string is just a host name. 


# my.cnf 

# example additions to my.cnf for MySQL Cluster 

# (valid from 4.1.8) 



# enable ndbcluster storage engine, and provide connectstring for 

# management server host (default port is 1186) 

[ mysqld j 

ndbcluster 

ndb— connectstring=ndb_mgmd . mysql. com 


# provide connectstring for management server host (default 
[ndbd] 

connect—string=ndb_mgmd . mysql. com 

port : 

1186) 

# provide connectstring for management server host (default 
[ ndb_mgm) 

connect —string=ndb_mgmd . mysql. com 

port: 

1186) 

# provide location of cluster configuration file 
[ ndb_mgmd ] 

con fig — file=/etc/config . ini 




Figure 2: Cluster parameters in my.cnf 


Figure 3 shows an example cluster configuration file. In this setup we have two data nodes and two 
replicas. This means that each node holds a complete copy of the database. Here we allow up to three 
MySQL servers to connect to the cluster. 
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[NDBD DEFAULT) 

NoOfReplicas= 2 
DataMemory= 500M 
IndexMemory= 100M 
DataDir= /var/lib/mysql—cluster 

[NDB.MGMD] 

Hostname= ndb_mgmd.mysql.com 
DataDir= /var/lib/mysql—cluster 

[NDBD] 

HostName= ndbd_2.mysql.com 
[NDBD) 

HostName= ndbd_3.mysql.com 

[MYSQLD] 

[MYSQLD] 

[MYSQLD] 


Figure 3: Example cluster config.ini 


Failure Scenarios 

If a MySQL Server node fails, it can be restarted which will reconnect it to the cluster. While the MySQL 
server is down, applications can connect to other MySQL servers connected to the cluster. 

If a data node fails, other nodes discover the failure due to missed heartbeats. Since all data is 
synchronously replicated within the cluster, new transactions can use another storage node which has the 
same data as the failed one. 

The continued operation of the cluster is not dependent on the Management Server. The management 
server only needs to be up when nodes are joining the cluster. You can however, have multiple management 
servers in the cluster. 


Schema Considerations 

There are several things you need to be aware of when designing (or adapting) database schemas to MySQL 
Cluster. 

Indexes 

There are three types of indexes in MySQL Cluster: 

• Primary hash index 

• Unique hash index 

• Ordered tree index 

Specifying a unique index from SQL will also create an ordered index unless USING HASH is specified. 

Primary Keys 

Every table has a primary key. If you declare a table in SQL without a primary key, NDB creates a hidden 
primary key. The primary key will have a primary hash index and an ordered index. You can specify 
USING HASH to skip the ordered index. 

Space Usage 

Mostly, the standard MySQL rules apply (as documented in the manual). However, a few things need to 
be considered. 
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Prior to 5.1, only fixed size rows are supported, so a VARCHAR(255) column will use 260 bytes of 
storage no matter how much data is stored in it. 

BLOB and TEXT columns use 256 bytes of fixed space in the row. Additional space is allocated in 2kb 
chunks as needed. 

In 4.1, each primary key or hash index requires 25 bytes plus the size of the key per record of In- 
dexMemory. The 5.0 release reduces this to 21 to 25 bytes per record. Each ordered index requires 10 
bytes of DataMemory per record. 

Warnings are written to the cluster log when 80% of DataMemory or IndexMemory has been used. 
Warnings are again printed at each 5% increment of usage. A supported method to query this information 
from the management client will be implemented in the future. 

New to 5.0 

With condition pushdown enabled (via SQL: set engine_condition_pushdown = on; or by flag to mysqld, 
-engine-condition-pushdown) conditions in the WHERE clause of an SQL statement can be evaluated on 
the data nodes instead of within the MySQL server. This can improve performance by five to ten times 
for such queries. This is due to savings in network traffic and the ability to execute the query in parallel. 
Less IndexMemory is required as the primary key is no longer stored in the index memory. 

The MySQL Query Cache now works with Cluster. 

New to 5.1 

It will be possible to use MySQL replication to replicate tables stored on the cluster. Replication will be 
handled by one MySQL server connected to the cluster which will record all updates to the cluster (from 
any of the MySQL servers) into the binary log. 

Non indexed attributes may be stored on disk instead of RAM. Indexed fields still have to be in memory 
and also the primary key hash index but all other fields can be on disk. 

Variable sized records will be supported. Currently, a VARCHAR(255) column would use 260 bytes of 
data no matter what the length of the actual record was. In MySQL 5.1 the minimum storage space will 
be used. This can reduce the storage requirements by sometimes up to a factor of five. 

Users will be able to define partitions based on the fields of the primary key. Partitioning based on 
KEY, HASH, RANGE and LIST handlers will be supported. 

Finding out more 

The MySQL Cluster|l] product page on the mysql.com web site provides a good overview of the product 
including data sheets, white papers and customer success stories. Also mentioned here is the range of 
support and training options available from MySQL AB. 

The MySQL Reference Manual[4] provides detailed documentation on the MySQL server setup as well 
as NDB. The MySQL Cluster chapter is a good starting place if you are already familiar with MySQL. A 
HOWTO is also available as an article in the MySQL DevZone[5]. 

Two forums are frequented both by developers and users. There is a web based forum[2] and a mailing 
list[3]. As always, it’s a good idea to read the FAQ in the manual and the list archives before asking 
questions - a lot of things have already been covered. 
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Abstract 

SQL injection attacks are serious threats to database servers in computer networks. In a SQL injection 
attack, a malicious user can insert a series of illegal SQL statements into the pre-defined one via some input 
interface [1, 11]. In other words, SQL injections manipulate SQL statements in a manner that they can 
be different from their intended use and the attacker can gain additional information from the database. 
SQL injection attacks can take advantage of flaws in a Web application to inject malicious scripts into the 
database. In this paper, we propose several novel countermeasures against various SQL injections. We 
believe that our novel schemes have merits compared to existing schemes. 


Introduction 

The necessity of using databases in a modern company is not unarguable in the information era. In 
computer networks, the security of databases always is a concern to database owners and users. Although 
various security mechanisms, such as using password and cryptography, have been deployed, many database 
systems are still facing unsolved security problems. 

SQL injection is one of common attacks against databases. SQL injection attack aims at peeping in 
the private information, modifying the information of target database, more seriously, controlling and 
destroying the database system and the OS platform. In a SQL injection attack, the attacker does not 
try to break the password or cryptographic protection (encryption, for example), but tries to inject some 
“legal” script through a standard input manner such as a textbox on a Web page. The injected script can 
gain some additional information from the database. 

Three protection mechanisms could be used to countermeasure SQL injection attacks: 

1. Proxy approach that separates the database from the web application. Every SQL statement is 
checked by the proxy. Only the valid SQL statement can approach the database. 

2. Filtering approach that filters sensitive words or keywords. Such filter can monitor the HTTP traffic 
and eliminate the malicious attacks. 

3. Use of parameterized SQL statements [5,6]. This strategy prevents the SQL injection at the beginning 
of application. Every input is checked by system automatically. 

These schemes have some drawbacks such as high computational overhead and difficulty in implemen¬ 
tation. 

There are some interesting schemes against SQL injections in the literature, for example, the work by 
Boyed, Keromytis [2], by Alfantookh [3], by Valeur, Mutz, Vigna [4], The scheme presented in [3] is based 
on filtering the sensitive words; however, filtering can never be perfect and efficient because of the richness 
and complexity of SQL. It is hard to predict what the attacker will do in the next step, for example, 
“select” = “SelecT” = “selecT” = “sE” + “leCt”. This also implies that it randomizes the keywords of the 
intended SQL statement to another form so that the injected keywords lose their meaning in a modified 
SQL interpreter and performs inefficiently with disposing irregular SQL expression because of matching 
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Figure 1: Overview of AUSELSQL 


keywords [2], The scheme proposed in [4] needs a huge database to support. Therefore, it attracts DoS 
(Denial of Service) attacks. We found that none of them meets the requirement of security and efficiency. 

In this paper, we propose a more practical, secure and efficient countermeasure mechanism against 
SQL injection attacks. The proposed protection mechanism is based on the concept of “keeping memory” 
technology and can detect any malicious injection by its “memory”. Our schemes are more efficient and 
secure, compared to other schemes. 


Previous works 

The most typical protection mechanism is “sensitive words filter”. As we have mentioned, Alfantookh [3] 
presented a so-called filter in practice. In Alfantookh’s scheme, the receiver module intercepts an HTTP 
request message and then passes it to the next stage. The request header processing module (parser) 
parses the header and extracts the lines that represent the user input. These lines are concatenated into 
one string that is passed to the decoder module, where encoded characters are transformed back to their 
ASCII representation. This step is necessary, because most of the attackers encode characters to prevent 
systems like AUSELSQL from detecting special characters. Finally the decoded input string is passed to 
the decision module where it is inspected for the existence of suspicious characters within the query string. 
If any suspicious characters are detected, the request is considered harmful and rejected. Otherwise it is 
passed to the web server which forwards the reply back to the client. 

Unfortunately, AUSELSQL is not secure and efficient in our view. That is because: (1) It is infeasible for 
a filter to provide a self-contained filtering rule about sensitive words due to the variation of HTTP encoders 
and the richness and complexity of SQL language. (2) The pure filter loses the close relationship with the 
specific intended SQL statement. For example, if an integer is expected by the intended SQL statement, 
the attacker can trigger the error of a database by flapping a character. (3) The high performance overhead, 
especially in a matching sensitive words period. 

Another retrofitting scheme of filtering is learning-based protection scheme [4] (see Figure 2). The 
protection models can characterize the profiles of a normal access to the database. These profiles are 
learned automatically during a training phase by analyzing a number of sample database accesses. Then 
during the detection phase, the system is able to identify anomalous queries that might be associated with 
an attack. The system taps into the communication channel between web-based applications and the back¬ 
end database server. SQL queries performed by the applications are intercepted and sent to the Intrusion 
Detection System (IDS) for an analysis. The IDS parses the SQL statements and selects the features of 
the query that should be modelled. A type inference process is performed on the selected features in order 
to support the selection of correct statistical models to be applied to the event, before a profile is selected. 
A profile is a collection of models, in which the features are fed, in order to train the set of models or to 
generate an anomaly score. 
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Figure 2: Overview of Learning Based Protector 

Their system is a learning-based anomaly detector, and thus requires that a training phase is performed 
prior to detection. If an anomaly score exceeds the maximum anomaly score seen during training by a 
certain tunable percentage, the query is considered anomalous and an alert is generated. We believe that 
this learning based system only provides some interesting secure strategies in SQL injection, since there 
are some potential problems. For example, since it is learning based, it still suffers from SQL injection if 
it has insufficient training data to initialize the profiles. However, when the huge profiles really build up, 
the cost of the system will become higher. Consequently, this method fails in practice. 

The most efficient and effective scheme is made by Boyed, Keromytis [2], the proxy works as a “modified” 
SQL parser, which only recognizes the SQL query in the proxy own syntax (see Figure 3). All the normal 
SQL key words will lose the original meaning. For example, the proxy can only recognize “selectl23” 
rather than “select” as the keywords to perform the “select” function in SQL query. Therefore, the proxy 
and the CGI application operate the SQL command under their own rules. If the received SQL statement 
is un-decodable by the modified SQL interpreter, the proxy rejects such SQL statement and redirects the 
URL to somewhere else. 

The scheme performs a perfect security if the attacker has no idea of the suffix of the key words in 
the SQL language. Such suffix works as a secret key in the whole system. The shortcoming is that 
the randomized and de-randomized process may cause accumulated overhead. It is also hard to deal 
with irregular intended SQL expressions. For instance, “se” + “lect” will be also regarded “se” and “lect” 
separately instead of randomizing “selectl23”. Hence, a false positive pops up. 

Our Contribution 

In this paper, we propose a novel proxy based scheme with a sound SQL structural protection mechanism. 
The proposed solution works in a total different way compared with the other existing protection mecha¬ 
nisms, although it shares some features of the existing schemes. The main points from [1, 7, 8, 9, 10, 12] 
provide basic attack methods in different angles. The proposed method extracts main features from those 
existed attack methods. [7, 8, 9, 10, 11, 12, 13] present some basic solutions for the prevention of SQL 
injection, such as proxy, and filtering. [20] uses the ODBC error message list table, which implies that 
potential SQL injection attacks may take advantage of those error information to control the database. 
[14, 15, 16, 17, 18, 19] introduce the knowledge of detection malicious intrusion. They are based on strings 
or characters expressions (normal characters, hex char, and so on). 

SQLrand [2] can also be classified to our direction. It appends a suffix to each SQL sensitive word and 
makes a normal SQL statement unrecognized to the system. In other words, they also keep the structure 










228 


SQL STRUCTURE REBUILDER: PREVENTING SQL INJECTION ATTACKS 



of the intended SQL statement though they do not mention or are not aware of this point. SQLrand has 
the same security level as our work. In fact, the difference is working efficiency. 

Other works based on filtering sensitive words [3, 4] are weak in both of security and efficiency. Although 
learning based protection mechanism [4] can grow gradually in the field of security, it needs a huge database 
to support itself. This attracts other DoS based attacks or becomes another SQL injection target itself. 
HTTP traffic based filter [3] is the worst one because it loses the close relationship with the specific intended 
SQL statement besides the low efficiency. 

Our proposed scheme considers SQL injection attacks in a reverse order to protect the integrity of 
the intended source. It has advantages over the solution based on scanning the malicious words is time 
consuming because of richness and flexibility of SQL language. The proposed method has nothing to do 
with matching keywords so that it can work in a more efficient way. Another merit of avoiding matching 
key words is false positive evasion. Such false positive is always possible upon irregular SQL expressions 
with a legal SQL syntax. 


Model 

We notice that any SQL injection attack changes the structure of the intended SQL statement. This 
attracts our attention to the SQL statement structure instead of SQL syntax and semantic. Therefore, we 
don’t need to match the sensitive words. In other words, the system keeps only the form of received SQL 
statements. The intended “selEct” will be kept as “selEct”. In our case, we build a proxy between the 
web server and client; when a SQL statement comes from web server, the proxy intercepts it and records 
its structure; any malicious injection makes the new structure mismatch the intended one so that it is 
rejected. For example, a logon page asks the client’s username and password. The intended SQL query, 

Select user from user 

Where userid = luserid and password = ’$password’ 

The proxy constructs its structure as, 

Select user from user 

Where userid = intended_number and password = intended_string 

If the attacker wants to log into a database server without authorization, he/she could make a SQL 
query as 
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Select user from user 

Where userid = 123 and password = ’ ’ or 1=1 
Upon receiving the query, the proxy rebuilds its structure as, 

Select user from user 

Where userid = intended_number and password = intended_string 
or intended_number = intended_number 

Therefore, the mismatching of these structures due to the injection occurs in the proxy. 

The Scheme 

Based on the above model, we now describe our scheme (see Figure 4). The key point in our proposed 
scheme is how to keep the integrity of the intended SQL structure effectively and efficiently. 

In the following, we give some basic notations to our scheme: 

1. Hash(expression) or H(expression): the hash value of the expression. 

2. Structure(expression) or S(expression): the structure of the expression. 

3. Intended SQL expression: the intended SQL expression by application system. 

4. Client SQL expression: the SQL statement that completed by client’s input. For example, 

select * from user where username=’Bob’ 
is a client SQL expression because the client fills in the required information of 
select * from user where username= ’ $usemame ’ 

The SQL structure rebuilder has the same architecture of the proxy based protection mechanism. Such 
architecture provides an additional protection to the system. Even if the proxy is broken by attackers, 
the database and web server are still safe. The proxy features as the interpreter for constructing SQL 
statement’s structures, comparing the received SQL structures and forwarding the validation information. 



Figure 4: Overview of SQL Structure Rebuilder 


Our protocol works as follows. 
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1. Instep 1, the client sends a request to the web server. For example, the client inputs http://mail.uow.edu.au 
as the URL address. 

2. In step 2, the server replies in response to the client, but the proxy A will record the SQL statement 
received from the web server in step 3. 

3. In step 3, the proxy A will build a structure that match the structure of the received SQL statement 
and hash this structure with the salt code. For example, upon receiving, 

Select * from user 

Where username = ’$username’ and password = password(’$password’) 
the proxy constructs a standard structure, 

Select * from user 

Where username = String and password = password (String) 

which we marked as structure 1. Then, the proxy hash the structure with some salt code, such as 
a number, 

Hash(Select * from user 

Where username = String and password = password (String)saltcode 

) 

The salt code here is used to make the hashed value unchangeable by the client. This salt code 
should be kept securely in the proxy. After these, the hashed value (structurel + saltcode) and 
the original SQL statement will be sent to the client. 

To have a more secure scheme in practice, a dynamic saltcode can be applied. We can take the 
advantage of a hash chain: W 0 , W x = H(W 0 ), W 2 = H(Wi), ■ ■ •, W n = H(W n -i). The saltcode is 
now W n , Wo is the beginning token. The final W n is determined by the hash chain. The various salt 
code can be produced by a hash chain. Make Wo = (intended SQL structure + a constant). 

The proxy secretly keeps the times N of the hash operations and the constant. Although W n is a 
constant for the specific SQL statement, it is actually different to other SQL statements compared 
with all of salt codes are constant. Therefore, W n and the salt code here are unpredictable by 
attacker. 

The saltcode is necessary. It works as a private key. We will give detail explains in the next section. 

4. In step 4, the client simply submits its input information and returns the hashed value of the original 
SQL statement structures that were sent by the proxy. Note the client can determine whatever he/she 
wants to input. For example, it will submit 

(a) Select * from user Where username = 'name' 

and password = password(’password’) 

(b) hashed value:(hash (structurel + saltcode)) 

5. In step 5, the web application forwards the submitted SQL statement to the proxy B upon receiving 
it from the client. 

6. In step 6, the proxy B rebuilds the structure of (a) and makes it as 

Select * from user 

Where username = String and password = password (String) 

which we mark as structure2. Then, the proxy compares hash (structurel + saltcode) with 
hash(structure2 + saltcode). If they are equal, then there is no SQL injection taking place. The 
proxy B forwards the valid client’s query to the database. 

7. In step 7, the database forwards the result to the proxy B. If the error information contained in the 
data packet, the proxy B will conceal the error and redirect the web page. 

8. In step 8, the proxy B forwards the valid result to the web application. 

9. In step 9, the web server reveals the result of the client’s SQL statement. 
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Discussion 

Security 

As what has been shown in step 4 and step 5, the salt code is necessary to help the system keep the 
integrity of the intended SQL structure. Otherwise, the proxies must keep the connection per session 
to make sure there is no modification on SQL statement. But handling all the connections will attract 
DoS and aggravate the proxy’s burden. The client can trick the proxy B if he/she knows the protection 
scheme. The attacker can send back H(client SQL structure) instead of H(intended SQL structure). 
Therefore, whatever SQL statement constructed by an attacker will has the corresponding structure of 
client’s SQL statement definitely. Therefore, when the proxy compares the two hash values, it must be 
equal. But the appended words “UNION” are actually injected words from the client. Consequently, the 
attacker tricks the protection mechanism by taking the advantage of no salt code in hash function. 

Another case is that the client may hold H(S(intended SQL statement + saltcode)) and try to 
inject a malicious expression. However, the protection system is still invulnerable with a private salt code 
because H(S(intended SQL statement + saltcode)) has the close relationship with the intended SQL 
statement and saltcode. The attack can only hold the hash value rather than change the hash value 
discretionarily. In other words, the attacker should obey the rule of the proxy. Otherwise, he/she will be 
definitely rejected. 

Overhead 

The protection mechanism we provided runs at a low cost for both of hardware and software. The proxy 
doesn’t care the SQL language itself but the structure of the string. Therefore, there are three merits in 
the system. 

(a) Avoiding matching the key words saves computational time. 

(b) The hash functions such as MD5 are very efficient. 

(c) The algorithm for constructing the SQL statement’s structure is efficient. 

The overhead in the communication and structure rebuilding process is considered light. 

Conclusion 

SQL structure rebuilder overcomes massive SQL injection attacks and provides a protection model against 
SQL injection. It protects system in a different angle. Any SQL injection changes the structure of the 
intended SQL statement so that if the structure of the specific SQL statement is preserved in a manner, the 
malicious SQL statement is detected definitely since its structure differs from intended one. The important 
factor in our scheme is structure “rebuilder”. It simply translates the incoming SQL statement to a specific 
form instead of analyzing the syntax and semantics. This strategy avoids dealing with the richness and 
complexity of the SQL language so that the overhead of a rebuild-process is negligible compared with 
other keywords matching based strategy. Another important process is how to preserve the constructed 
structure. In order to keep the intended structure and make it unique to a specific SQL statement, the 
parameterized hash function is applied. The parameter/saltcode is kept secret so that the hash value is 
unchangeable during the procedure. These two crucial factors make any modification with the intended 
SQL statement detectable. 

We believe SQL structure rebuilder is a very practical protection mechanism that can solve SQL injection 
with a high efficiency. Since it can be easily applied to existing web applications, we also believe it will 
become a direction of prevention SQL injection in the future. 
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Abstract 

Most computer program’s store application data in various ad hoc file formats which leads to host of 
compatibility and interoperability problems. In recent years, the trend has been to use XML to store 
application data, which is certainly an improvement over the ad hoc approach but still has shortcomings. 
This paper argues that the use of embedded transactional database engines to store application data is 
almost always superior to ad hoc disk files and usually better than XML. 

Introduction 

An important part of a large number of application program’s in use today is the ability to create, modify 
and read filesystem entries containing application specific data (hereafter “application files”). Application 
files may contain user documents, program configuration options, license keys or any of a host of other 
categories of data. For the purposes of this paper, we assume that all application files are small enough to 
be processed online. 

Despite the fact that so many programs create and use application files, the general problem received 
little attention until the recent advent of “standard” formats for structured data, such as XML [XML]. 
Where previously a program would have saved state in an application-specific format, data is now being 
formatted as an XML document for storage. 

Although using XML simplifies many application programming tasks and provides other benefits as 
well, XML does not provide a solution for all of the generic problems surrounding application files. This 
paper examines the use of another technology, embedded database systems, in the application file domain. 
In the opinion of the authors, embedded database systems provide many of the benefits of XML and also 
offer solutions to problems not addressed by XML. 

Problem Definition 

Generally, implementations of systems that read and write application files must perform two tasks: 

• Serialization and deserialization 

When the program creates or updates an application file, part of the programs state is converted 
to a serialized form suitable for storage. Similarly, when the program reads an application file the 
program state is updated by deserializing the serialized data. 

• Interfacing with the file-system 

To read or write an application file, the program must invoke various operating system specific 
functions to interface with the file-system. For some applications this can be very simple. For systems 
with slightly more complicated requirements, for example an application that requires exclusive access 
to files, it can be a major source of program errors and limitations. 

As with any programming problem, the implementor has to decide whether or not to employ third party 
software components to perform these functions. Using third party solutions can simplify development and 
lead to richer, more functional programs. 

Recently, many applications have begun to format application files as XML documents. This allows 
them to use a third party software component for the first of the above tasks, serializing and deserializing 
program state. Embedded databases offer a feature-rich prepackaged solution to both problems. For 
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the purpose of analysis, this paper divides programs that use application files into the following broad 
categories: 

Ad-hoc file solutions In this class of solution, the program contains implementations of both of the 
tasks listed above. The format of the application files is not usually standard in any way. This is by 
far the most common solution in use today. 

XML file solutions This class uses a standard solution for the serialization/deserialization task. The 
format of the application files conform to a flexible standard for storing structured data, such as 
XML. The majority of the remarks made in this paper about XML files apply to other files formated 
using other such standards as well, but XML is today ubiquitous enough in this role that we feel 
justified in addressing it specifically. 

Embedded database solutions Embedded database solutions use an integrated third party component 
to implement both of the tasks listed above. In many cases this class of solution have all of the same 
benefits as XML file solutions, as well as extracting superior functionality from the filesystem layer. 

The advantages of using XML as a file format are by now well known [XML], Briefly, XML files are 
self-describing and contain semantic as well as instance data. This makes the development of generic tools 
possible. The volume of tools currently available to manipulate XML files is very large, and includes 
powerful document verification, manipulation and query languages. Another advantage is that XML files 
consist entirely of legible text, so can be read by humans. 

The advantages of using embedded database files are less well understood. They are introduced in the 
following sections. 


Embedded Database Systems 

An embedded database system is a software component that provides the same functionality as any other 
database system, targeted storage and retrieval of information. It is distinguished by the fact that the 
database code is linked directly into the client application process. Instead of contacting a separate server 
process to execute queries on its behalf as is the case with a traditional database system such as PostgreSQL, 
the embedded database library linked into the application usually accesses a filesystem containing the stored 
data. For this paper, we consider only the subset of embedded databases that meet the following criteria: 

• The information is stored in a single disk file. 

• Storage and retrieval of information is Atomic, Consistent, Isolated, and Durable (ACID) [ACID|. 

• Data formats are self-describing. In other words, a program can be written that will read all data 
from the database without prior knowledge of how the data is organized within the database. 

• The same file is usable on all platforms (including little-endian and big-endian platforms). 

Database engines that meet these criteria include Firebird embedded version [FB], Metakit [MTK], and 
SQLite [SLT1] [SLT2]. Berkeley DB might be added to the list except that it supports only key/value pairs 
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which are not really self-delimiting. Embedded MySQL, HSQLDB and Cloudscape/Derby are omitted 
because they store information across multiple files. PostgreSQL, SQL Server, Oracle, DB2, and a host of 
other popular database engines are excluded because they all operate in client/server mode only - they all 
require a separate server process to perform the actual disk I/O. 

The thesis of this paper is that very often using an embedded database library to implement application 
files provides significant advantages over using ad-hoc or XML files. Often, designers reject or do not 
consider an embedded database solution even when an application would receive great benefit from the 
features that one would provide. This is possibly because the developer community is largely unaware of 
the available technology, or may simply be because the term “database” is associated with heavy workloads 
and complicated installation procedures. 


Comparison of Ad-hoc, Xml and Embedded Database Solutions 

Advantages of the Ad-hoc File Approach 

Using either an XML library or an embedded database system to implement application files adds an extra 
dependency to a program. Application designers may wish to avoid this to improve portability. However, 
because they are performance sensitive, many XML libraries and embedded database systems are written 
entirely in highly portable C code. Except in the most demanding cases, few scenarios should exclude 
XML or embedded database approaches on the grounds of portability. 

One class of application file for which embedded database or XML format may not be suitable are media 
files (for example digitally recorded music or video footage). These files usually consist of compressed data 
stored in a highly optimized manner to be read and processed sequentially. However storing many small 
media files used by an application as blobs of data as part of an embedded database or XML document 
may be an appropriate strategy. 

Advantages of the XML File Approach 

Using XML has two big advantages over the ad-hoc file approach. Firstly, it reduces the programming 
effort required to design and implement the system for serializing and deserializing data saved in the 
application file. Secondly, it allows users and developers to utilize the large variety of tools available, 
which can simplify user and programmer tasks in both expected and unanticipated ways. In general, more 
open-source programming tools are available for use with XML than with embedded database systems. 

As well as the main difference between XML and embedded database approaches noted earlier - that 
embedded databases also help an application to take advantage of complicated file system capabilities - 
there is a significant difference between the serialized formats used by each approach to store data. The 
XML format was designed to be as simple as possible. By contrast, the primary consideration when 
designing an embedded database file format is the desired feature set of the database engine. Because 
of this, embedded database file formats can be very complicated things. Data stored in an embedded 
database should only be considered accessible when the original database engine is available, whereas an 
XML file may be queried or edited either directly or with any available XML toolset. To alleviate this, 
embedded database systems often provide built-in functions to export data to a more accessible format for 
transfer to other systems. For example, SQLite ships with a tool to create an SQL script from an existing 
database. The SQL script may be processed by any compatible database system, embedded or otherwise, 
that supports SQL to recreate the contents of the original database. 

Files in XML format may be processed incrementally, whereas embedded database files rarely can. 
Whether or not this is important depends more on how the application file is used than on it’s content. For 
example, a large spreadsheet file that is frequently downloaded and viewed in a browser program might be 
better stored as an XML document to facilitate incremental display. Or, the same spreadsheet file accessed 
and updated primarily on a local workstation may be better stored as an embedded database, for reasons 
listed in the next sub-section. 

Very small amounts of data may result in relatively large embedded database files. For example, the 
minimum size of an SQLite database file is 2KB, whereas the size of an XML document is always roughly 
proportional to the amount of data it contains. This, and the incremental parsing capability mentioned 
above, mean that XML is more suitable if a combined application file/message format is required. 

Advantages of the Embedded Database System Approach 

Using an embedded database system to implement application files offers similar benefits to XML over 
the ad-hoc file approach. Programming effort is reduced even further than when using an XML approach, 
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because the details of both serializing and deserializing application state and interfacing with the filesystem 
are taken care of by the third party library. 

Depending on the specific embedded database system used, powerful user tools may be available. SQL 
[SQL] based systems with support for the ODBC [ODBC1] [ODBC2] [ODBC3] standard can use common 
tools such as Microsoft Excel and Microsoft Access to examine and edit database files. Programming tools 
for embedded databases are normally limited to the native query language of the database (for example 
SQL). Having said that, the query languages are generally very powerful. Additionally, the database file 
itself is usually structured to support creation of indexes to speed up specific queries and updates. For this 
reason, if an application is required to read or write only a small part of an application file, an embedded 
database approach may perform significantly better than an XML or ad-hoc file solution. 

Applications and application suites that use embedded databases for configuration files are less prone 
to configuration file proliferation. When using an ad-hoc or XML file approach, if two separate subsystems 
require configuration files, it can be difficult to organize the software to use a single file. For example, 
the preferences directory of the Mozilla suite contains over a dozen files in four different formats. When 
using an embedded database solution, combining configuration files for disparate subsystems is much more 
natural. Each sub-system can open and use the same database separately. All that is required is to 
partition the database namespace to avoid clashes between subsystems. Issues to do with simultaneous 
attempts to write to the database by different subsystems are all handled by the database engine. 

The extra functionality extracted from the filesystem layer by an embedded database system can be 
summarized as “file locking and the ACID model”. At the simplest level, most embedded database systems 
allow an application to obtain a shared or exclusive lock on a database file. In the absence of a prepackaged 
solution, even this simple and useful functionality often goes unimplemented due to the difficulty of dealing 
with filesystem interfaces in a portable way. For more sophisticated applications, the biggest advantage 
of an embedded database approach over an XML file approach is the ACID model offered by embedded 
database systems. A rough definition of the properties of the ACID model and the benefits of them to 
common application file scenarios is as follows: 

Atomicity states that a database transaction is either completely committed to the database or not com¬ 
mitted at all. This means that if database modifications A and B are performed within a transaction, 
there is no scenario where one modification takes effect but the other does not, even if a hardware or 
software failure occurs. This property complements “Durability” by ensuring that the database con¬ 
tents do not become internally inconsistent due to a program crash or other problem. Like durability, 
this guarantee is valuable in a large range of situations. 

Consistency refers to the ability of the database to encode high-level data constraints as part of the 
database schema. If the database is updated in such a way to violate a constraint, the entire transac¬ 
tion is rejected and the database remains unchanged. This property may be useful during development 
or verification of designs that use application files by helping to ensure that internally inconsistent 
files are not accidentally created. 

Isolation ensures that if multiple application programs attempt to write to the database at the same time, 
the write operations are somehow managed so that they do not interfere with each other. Embedded 
database systems almost always implement this property by serializing write operations. This prop¬ 
erty can be useful for some classes of application file, for example configuration files being used by 
two applications simultaneously, or a cache file shared by two or more web-browser applications. 

Durability states that a power, software or hardware failure unrelated to the persistent storage device 
should not be able to (or at least be very unlikely to) corrupt the database. This guarantee is 
advantageous in almost all situations. 

Considered together, the benefits of the ACID model described above are widely applicable to systems 
that use application files. 


Open-Source Embedded Database Systems 

The three most common open-source embedded database systems that meet the criteria outlined earlier 
are Firebird, Metakit and SQLite. This section briefly describes the similarities and differences between 
them and the way this may influence their applicability to the problem domain being investigated. 

Recently honored with a Google-O’Reilly Open-Source Award, SQLite holds its own against any open- 
source or commercial embedded database system. Now over four years old, featuring over 20,000 individu¬ 
ally written test cases and in use in a myriad of applications and platforms, SQLite is a highly polished and 
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optimized database engine worth considering in almost any context. SQLite features an almost complete 
implementation of SQL92 used to access data stored in a single file. Creation of SQL indexes, which the 
database engine uses to accelerate queries, is supported. The complete ACID model, as described earlier, 
is implemented. Adding the library to an application usually adds between 150 and 230 KiB to the size 
of the shipped application package, depending on the features enabled during compilation. As well as the 
library itself and the bundled SQL command-line interface, both open-source and commercial graphical 
tools have been created by third-parties for use with SQLite. By using the open-source ODBC interface, 
SQLite databases may be examined and manipulated by powerful generic tools such as Microsoft Access 
or Excel. 

Slightly older than SQLite, and also somewhat lighter at around 120 KiB, Equi4 Software’s Metakit is 
a different kind of embedded database. Like SQLite, Metakit stores an entire database in a single file. Also 
like SQLite, a database is conceptually comprised of one or more tables (“views” in Metakit nomenclature) 
populated by zero or more records that each consist of the same number of fields. However instead of using 
an interpreted language like SQL to query and manipulate the database, Metakit provides a straightforward 
API in the application programming language. Available programming languages include C/C++, Tel, 
Perl, Python and others. One interesting feature of Metakit is that a column value may contain an 
entire table. This can make storing the hierarchical data structures that often occur in applications 
programming (and therefore application files) considerably easier. Although Metakit does not provide any 
support for consistency checks, other parts of the ACID model axe more or less supported. Metakit files 
are not as durable as SQLite files in the presence of software or hardware failures, but they still offer 
considerable advantage in this respect over the average ad-hoc file implementation. Several open-source 
tools for examining Metakit databases interactively are available. 

Although it is primarily seen as a client/server database, Firebird also features an embedded version 
that stores an entire database in a single file. Presumably as an artifact of this, Firebird is huge compared 
to SQLite or Metakit, adding almost 2000KB to the footprint of a deployed application. Having said 
this, the SQL interface provided is a more complete implementation of SQL92 than that featured by 
SQLite and features many features from SQL99. Firebird is mature software with a history going back 
more than 20 years. When deployed as an embedded database system, it is not possible for multiple 
clients to simultaneously access a Firebird database. Depending on the application in question, this may 
or may not be desirable behavior. However, Firebird allows applications written to use the embedded 
database to upgrade to the client-server version with little or no code changes. Again depending on the 
application, being able to use either an application file or a database may be a desirable flexibility. Several 
end-user tools, including an SQL command-line client, are available for working with Firebird databases. 
Additionally, by using the ODBC interface, generic tools such as Microsoft Access or Excel may be used 
to query or manipulate database files. 


Case Study 1 

One of the most ubiquitous open-source applications is the Mozilla application suite, which consists of a 
variety of applications including a web-browser, electronic mail system, calender tool and others. Configu¬ 
ration and profile data (for example, a bookmarks list) is stored across a large number of application files 
in a variety of formats [REFERENCE]. Some files contain data used by a single application only, others are 
shared by multiple suite applications. On a UNIX-like system, these files are stored under the “.Mozilla” 
sub-directory of the users home directory. For a typical user, the .Mozilla directory may include: 

prefs.js - A file of javascript code that sets application preferences when executed. This file is shared by 
several components. 

bookmarks.html - An XML file containing bookmarked URLs used by web-browser components. The 
tags used in the file are such that the file may also be treated as XHTML and displayed by a web- 
browser. 

history.dat - A file containing browser history formatted using the “Mork” format. Mork is a standard 
format used to store serialized structured data developed for internal use by the Mozilla project. 
Within our analysis structure, it fulfills the same role as XML. However, although it is less verbose 
than XML, the Mork format is difficult to extract data from, and only the lowest level programming 
tools exist. For these reasons, the format has recently been falling out of favor within the Mozilla 
project. 

cookies.txt - A text file containing saved browser cookies used by web-browser components. Each line of 
the file contains a single cookie record. The fields of each record (cookie value, source website, expiry 
date etc.) are separated by TAB characters. 
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cert8.db A Berkeley Db file containing stored SSL certificates shared by several suite applications. 

Many others... 

Recently, work has begun on the “Unified Storage” project for Mozilla version 2 [MOZlj. This project 
aims to use SQLite to replace the various configuration files that currently make up a Mozilla profile with 
one or more embedded database files. Because the ad-hoc way in which profile storage has been approached 
in the past has led to multiple implementations of similar functionality, it is anticipated that using the 
SQLite embedded database engine may reduce the application suite footprint slightly. The overall goals of 
the Unified Storage project are presented as: 

• Provision of a unified interface for storing and searching through data for all Mozilla components and 
extensions. 

• To provide Mozilla core components and extension authors with tools to enable richer interaction 
with user data (for example by using SQL). 

• The elimination of the need for components to write their own file serialization/deserialization rou¬ 
tines. 

• The elimination of multiple file formats from Mozilla profiles. 

Aside from the above, some mozilla applications such as the email tool store valuable user information. 
Storing this information in an embedded database to take advantage of the durability and atomicity 
guarantees may be prudent. Additionally, an entire mozilla profile, which currently can consist of dozens 
of files in a handful of sub-directories may be reduced to a small number of embedded database files (possibly 
even just a single file). This makes some profile management tasks significantly easier, for example the 
backing up or transfer of profiles between machines. 

Although not a primary concern of the Unified Storage project, the designers note that using an 
embedded database system like SQLite makes it easier for applications outside the mozilla framework to 
access profile data. This could be useful for exporting browser data such as bookmarks or history from 
mozilla to a third party web-browser, or for performing complex queries on data using raw SQL. 

Using an embedded database also goes some way toward addressing another longstanding mozilla issue; 
the sharing of profiles between simultaneously executing applications. Currently, mozilla does not allow 
more than one application to simultaneously access profile data. This problem is easily visible to users 
on UNIX-like systems. If a user attempts to start a second copy of a mozilla application, for example the 
firefox web-browser, they are presented with a dialog box that allows them to select or create a profile 
other than the default, which is being used by the original instance. If the second profile is modified, 
the modifications may be manually merged back into the original at a later time. (On some systems, 
executing the command “mozilla” or “firefox” may cause an existing application instance to create a new 
main window. In this case to observe the phenomena described here, start the second application on a 
different XI1 display from the first.) 

The ACID model provided by embedded databases solves some of the problems with sharing mozilla 
profiles between applications. However some elements of application design may also need to change before 
this is can be achieved. Most embedded database systems (including SQLite) do not offer any form on 
inter-application notification procedures, which would presumably be required. There is also some interest 
within the mozilla community in sharing profiles between applications running on remote machines [MOZ2]. 
Although an embedded database system cannot directly contribute to that requirement, one solution would 
be to use a traditional database architecture (such as postgresql) when remote profile sharing is required. 
A system that can be configured to use either a remote SQL database or a local embedded SQL database 
may be easier to construct and maintain than one that can use either a remote database or collection of 
ad-hoc files. 


Case Study 2 

Monotone [MTN] is an open-source software-configuration management (SCM) system, similar in purpose 
to systems like CVS, Subversion, Dares, Arch, and Git. To quote from the website: 

“[Monotone] provides a simple, single-file transactional version store, with fully disconnected operation 
and an efficient peer-to-peer synchronization protocol. It understands history-sensitive merging, lightweight 
branches, integrated code review and 3rd party testing. It uses cryptographic version naming and client-side 
RSA certificates. It has good internationalization support, has no external dependencies, runs on Linux, 
Solaris, OSX, windows, and other unixes, and is licensed under the GNU GPL.” 
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Other SCM systems usually store information in many separate files in a “source code repository”. 
Monotone departs from the usual practice by storing all data in a single database file accessed by an 
embedded database engine (SQLite in this case.) The use of an embedded database gives Monotone a 
number of advantages: 

• The entire source code repository is now contained in a single file, making in particularly easy to 
SCP or FTP to a different machine, send to a coworker as an email attachment, or copy to a flash 
disk. 

• Updates to the repository are atomic, consistent, isolated, and durable (ACID). These are very 
important properties to have in an SCM but are also commonly missing from other SCM systems. 

• The database engine automatically handles synchronization and locking when two or more instances 
of Monotone try to update the same repository at the same time. 

• The database engine automatically takes care of efficient storage and retrieval of data and index 
maintenance, allowing the Monotone developers to ignore those problems and focus on their core 
SCM functionality. 

• The state of the repository can be examined for testing and analysis or by third-party tools using 
standard SQL statements instead of having to decode a special-purpose file format. 

• All changes to the repository are manifest as readable SQL statements which are logged into an 
internal diagnostic buffer for testing and debugging. 

The use of an embedded SQL database engine also leaves open the possibility of porting Monotone to 
an enterprise-scale client/server database engine in the future. However, the Monotone FAQ points out 
that such a port may be less desirable that it seems at first. The only possible advantage to using an 
enterprise-class database engine is scalability but the entire 70,000 commits of GCC’s history fits easily in 
a one or two gigabyte SQLite database, ft is difficult to imagine a need to scale much larger than that. On 
the other hand, moving to a client/server database engine greatly increases the administrative overhead of 
managing the source code repository. 


Conclusion 

In rare cases, such as when designing media formats or it is imperative to avoid introducing new depen¬ 
dencies, using the ad-hoc approach to the application file problem can be justified. However in the vast 
majority of instances, programming effort is reduced and quality increased by using a third-party library 
to format the application file data in a standard form, such as XML. This is now widely recognized and 
many new applications use XML as an application file solution. 

What is less widely recognized or acted upon is that using an embedded database system to implement 
application files can offer significant advantages over XML files, the most prominent of which being: 

Reduced programming effort Because embedded database libraries solve a greater part of the appli¬ 
cation file problem than XML libraries, there is less work left for the application programmer to 
do. 

Sophisticated file locking Embedded databases also do a better job of interfacing with operating spe¬ 
cific file-system interfaces to obtain richer functionality than is usually practical for the application 
developer. The most obvious manifestation of this is locking. Embedded databases lock and unlock 
files automatically to ensure the maximum concurrency without risking write collisions. Also, sys¬ 
tems that use embedded database systems to implement application files usually have access to a 
range of high level, cross-platform file locking primitives. 

Protection against file corruption The ACID model offered by embedded database systems protects 
against corruption that may occur if a hardware or software failure occurs while the application file 
is being updated. 

Complexity Management When using an embedded database solution, storing diverse information, 
possibly from multiple independent sub-systems, in the application file is a simple matter of parti¬ 
tioning the namespace. Locking and arbitration of read and write requests from disparate components 
is handled automatically. In dire cases, using an embedded database may prevent a single application 
file format from being split into multiple files, with all the disadvantages that that brings. 
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The chief arguments for using XML over an embedded database format are that XML can be processed 
incrementally when transmitted over a network and the large variety of powerful programming and user 
tools available. The first argument is compelling in some circumstances, for that class of application that 
requires a uniform file and message format (for example HTML) an XML formatted application file is 
preferable to an embedded database. The second argument is less persuasive, as powerful tools exist for 
embedded databases too. Because embedded databases are self-describing, tools can even be developed 
to convert the contents of an embedded database to an XML document if required. Nevertheless, if an 
application would benefit from access to a certain programming or user tool available for XML, this may 
be a reason to reject an embedded database method. 

Although not suitable in all cases, none of the technical arguments suggested in this paper fully explain 
why embedded databases are not in widespread use as application file formats. This may be due to the 
association between the term “database” and large complicated systems, or may be because the developer 
community is as yet unaware of the widely applicable benefits offered. If so, this is a pity, as there are many 
applications that store data in files for which an embedded database system should be seriously considered. 
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1 Introduction 

Single sign-on implies different things to different people, but generally it means the ability to reduce the 
number of mechanisms of user authentication across different systems to (ideally) one. A related notion is 
the idea of Identity Management, which aims to reduce the number of user identities to simplify manage¬ 
ment and improve useability. This can be achieved by a variety of mechanisms including consolidation of 
identity stores, or synchronisation of identity information. 

There are three main benefits to deploying a single sign-on system within an enterprise: 

• Convenience - users have fewer passwords to remember. 

• Security - fewer passwords mean less chance of them being written down; fewer identities mean less 
likelihood of stale accounts proliferating. 

• Manageability - managing multiple sources of identity incurs a high cost in both administration and 
time. 

However, single sign-on is not without its risks and challenges. This paper looks at the problem from 
the UNIX perspective, detailing some of the major issues. It describes the different approaches and how 
these integrate with the UNIX platform. Lastly, it evaluates options for integrating a UNIX single sign-on 
environment with Windows and Active Directory. 

2 Risks and Challenges 

2.1 Single Sign-On = Single Point of Failure 

The most obvious risk of moving to a single sign-on system is that it also creates a single point of failure. 
The compromise of a single authentication credential will allow an attacker access to all systems for which 
the user who is authenticated by that credential is authorised. This problem is compounded by the fact that 
single sign-on solutions tend to have a “lowest common denominator” effect, where for practical reasons 
only the weakest authentication schemes (i.e. passwords) can be used, often in the clear. This means that 
every time the user has to re-enter their password, a possible point of compromise is created which has to 
be protected against. 

Ideally, a single sign-on system should use the strongest possible authentication system available. If 
passwords are to be used, care must be taken to ensure that they are never passed in the clear, or passed 
to systems which may be easily compromised. 
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2.2 Authorisation 

In an enterprise without a single sign-on deployment there are usually multiple UNIX systems, each with 
their own password files. Access to a particular host is determined by whether or not a particular user has 
an account on that particular system. However, when you move to a single sign- on system, users suddenly 
have an account on all systems everywhere. This key problem is poorly addressed in many single sign-on 
deployments. 

2.3 Migration of UIDs/GIDs 

One of the largest problems with migrating to a centralised single sign-on system is dealing with UID and 
GID conflicts. When you have many isolated systems there is a strong likelihood of users having different 
UID/GIDs on different systems, and of there being overlap between some systems. This is a hard problem 
without an easy solution. Not only does numbering need to be consistent among the various passwd/group 
databases, but also across filesystems, some of which may be mounted by NFS. For this reason some 
solutions attempt to separate the identity space into different zones each with its own UID/GID space, 
however this just imports the whole mess into the new environment without fixing the problem. One 
approach is to use UIDs which are unassigned across all the systems to create a temporary UID mapping 
for user accounts that will not overlap. However, the problem is best addressed on a case by case basis. 

3 Single Sign on for UNIX 

3.1 Unix Integration Points 

3.1.1 PAM (Pluggable Authentication Modules) 

PAM [16,13] integrates low level-authentication schemes into a high level API. Modules are implemented as 
shared objects with a number of well defined entry points, and are configured by a text file: /etc/pam.conf. 
PAM allows authentication mechanisms to be stacked and allows rules to determine whether authentication 
to a given module is required or optional. Applications such as login, su, xdm etc are integrated using the 
PAM API. PAM is supported on most flavours of UNIX and there are a variety of PAM modules available 
ranging from simple password authentication to smartcard login. 

3.1.2 NSS (Name Service Switch) 

NSS [2,17] allows replacement of local config files (/etc/passwd, /etc/group, etc) with centralised databases. 
Like PAM, NSS modules are dynamically loaded and configured from a configuration file (typically /etc/nss- 
witch.conf). The range of configuration files or databases differs from implementation to implementation, 
but typically the /etc files passwd, groups, hosts, aliases etc. are supported. The nsswitch.conf file allows 
multiple sources to be configured for each database. For example the hosts database can be resolved using 
a local file (/etc/hosts) or via DNS. 

NSS requires modifications to C API functions such as getpwent and gethostbyname to call the under¬ 
lying NSS modules. This allows applications to utilise NSS functionality without having to be rewritten. 
It is worth noting that NSS functions are called very often by system utilities such as Is, so modules need 
to be implemented for high performance and robustness. 

3.2 Authentication and Identity Services for Single sign-on 

A number of authentication and identity services have been developed that can integrate with the PAM 
and NSS APIs. Notable among these are NIS, LDAP and Kerberos. This section describes these services 
and discusses their suitability for single sign-on on UNIX. 

3.2.1 NIS (Network Information Service) 

NIS [7] is an RPC based client server system developed by Sun Microsystems to provide synchronised config 
files across multiple UNIX servers. Information is stored in a data file called a map. NIS clients use RPC 
broadcasts to discover servers, and NIS provides scalability through a master/slave replication scheme. A 
NIS implementation is available with many UNIX operating systems, and it has been widely deployed. 

NIS is considered insecure as it provides unauthenticated cleartext, remote access to maps, some of 
which contain sensitive information (e.g. passwd files). A second more serious problem is it is very easy 
to spoof NIS servers to provide false information as there is no authentication of these services [22]. In 
addition, there is no standard support in NIS for password aging, which is an important risk mitigation 
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strategy for password based systems. For these reasons, many organisations are attempting to phase out 
NIS in favour of other schemes. 


3.2.2 LDAP (Lightweight Directory Access Protocol) 

LDAP [20| is a simplified version of the X.500 [6] DAP protocol developed at the University of Michigan. It 
provides a hierarchical distributed database of objects using a configurable schema, and supports authen¬ 
tication via simple password, password over SSL or SASL/GSSAPI. With the addition of the RFC2307 
[4] schema for storing UNIX identity information, LDAP has become a very popular mechanism for au¬ 
thentication and identity management for UNIX. The pamJdap [15] and nssJdap [14] modules provide 
authentication and identity service integration with UNIX respectively. 

Because of the distributed nature of LDAP it is possible to create a scalable solution. LDAP allows you 
to delegate parts of the namespace (i.e. subdomains) to different servers. It is also possible to replicate 
servers. 

Many applications support LDAP as an authentication database, making it a convenient choice for 
unified login. This is usually done by having the application prompt a user for a password, and then using 
the password to perform a bind (authentication) to the LDAP server. While this approach is convenient, 
it can make the password vulnerable to attack if not used carefully. LDAP servers should be configured so 
that they will not accept simple binds (authentication in the clear); rather they should require either SSL 
or SASL/GSSAPI authentication. Care must also be taken to ensure that when a password is entered by 
a user that it does not pass in the clear between the user and the application (for example if using basic 
authentication with a web browser over an unsecured connection). 

One further criticism of LDAP is that it has limited and awkward interfaces for addition and manage¬ 
ment of user and group information. 

Despite these concerns, LDAP is a practical and viable alternative to NIS as an authentication service 
and is becoming increasingly common in enterprise deployments. 


3.2.3 Kerberos 

Kerberos [12] was developed by MIT for the express purpose of providing a single sign-on system based on 
a trusted third party. It uses a centralised Key Distribution Centre (KDC) comprising an Authentication 
Service (AS) and a Ticket Granting Service (TGS). Users authenticate to the AS with a password (or private 
key with PKINIT) and receive a Ticket Granting Ticket (TGT) that can subsequently be presented to the 
TGS to obtain a service ticket to access a kerberised service. There are three main implementations of 
Kerberos: the original MIT implementation [11], Heimdal [3], and the implementation in Microsoft’s Active 
Directory [9]. Kerberos supports distribution and replication of KDCs for scalability and to enable cross¬ 
domain authentication. Some recent implementations of Kerberos also support discovery of servers using 
DNS SRV records. 

One interesting feature of Kerberos is the ability to use delegation. This allows a credential to be 
forwarded to a service so that service may act on behalf of a user. An example is SSLI where a user may 
wish to SSH to one server and then to a second server without having to re-enter their credentials. 

A benefit of Kerberos is it can be extended to support authentication mechanisms other than passwords 
without the need to modify all the Kerberised services. For example the PKINIT [18] protocol can be used 
with a smartcard for initial logon. This enables a strong mechanism to be used for authentication mitigating 
one of the major risks of single sign-on (the tendency to the lowest common denominator). 

Many systems provide a pam_krb5 module that integrates Kerberos with the UNIX login. Because 
Kerberos only provides authentication it is typically used in concert with another identity service such 
as LDAP. Many LDAP servers support SASL/GSSAPI binds with Kerberos, allowing a very effective 
interoperability mechanism. 

One issue is that maintenance of Kerberos trust and server information is a little awkward; it requires 
each host to maintain a file (usually /etc/krb5.conf) which contains trust information and the locations 
of servers for different realms. However, recent implementations of Kerberos are beginning to adopt some 
practices used in Active Directory for referrals and DNS SRV record lookups for server location that 
mitigate many of these problems. 

Another disadvantage of Kerberos is it requires all services to be modified (or Kerberised) to allow 
them to be part of the single sign-on environment. Fortunately, a very large number of applications 
already support Kerberos, including FTP, TELNET and SSH and some web browsers. 
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3.3 Conclusions 

The security problems with NIS effectively rule it out as candidate for single sign-on on UNIX, leaving the 
most likely choices to be LDAP or a combination of LDAP and Kerberos. 

One of the problems identified early on, is the need to ensure that any authentication mechanism for 
single sign-on needs to be as strong as possible. For this reason, Kerberos makes an excellent choice for 
unified login. Kerberos is generally easy to configure, and the protocol ensures that passwords are never 
sent in the clear across the network. Most importantly, with Kerberos a user need only ever type in their 
password once. 

For applications that do not support Kerberos it is recommended that where possible these be “front- 
ended” by a system that does (e.g. HTTP using SPNEGO). Alternatively, if an application supports LDAP 
as its backend, this can provide an effective interoperability mechanism. 

However, the authorisation problem is not easily solved in the general case. One suggestion is to use 
/etc files with NSS for local overrides (either by only including users authorised to that system, or by 
adding dummy entries for excluded users with bogus password and shell entries). Some PAM modules 
(such as pamJdap) also support specific group/host based authorisation, and it is possible to further limit 
remote access by using tcpwrappers. None of these approaches is entirely satisfactory however as they do 
not provide a central management point for authorisation. 


4 Integrating with Windows 

While these solutions should provide a reasonable basis for addressing single sign-on across a range of UNIX 
systems, things become more complicated if (as do most enterprises) you also have Windows systems that 
you need to sign on to. In this section, we consider how to extend the suggestions in section ?? to provide 
interoperability with Windows based systems. 

4.1 Active Directory 

If you have a sizeable deployment of Windows desktops you will almost certainly have an Active Directory 
server [10]. Active Directory was first released by Microsoft in Windows 2000 to replace the Windows 
NT domain controller with a (mostly) standards compliant infrastructure. Active Directory integrates 
Kerberos and LDAP into a single service, providing both authentication and directory services. It provides 
scalability and replication including “site awareness” (the ability to have a topology of servers based on 
physical location with replication strategies determined by link cost). Active Directory also supports auto 
discovery of servers including the ability to disconnect and reconnect laptops at different sites, and a multi¬ 
master replication strategy enabling high scalability. In addition, the most frequently used attributes of 
all objects are cached in a Global Catalogue server, enabling LDAP searches that would normally require 
referrals to several different servers to be performed on a single machine. 

One other feature is the ability to restrict desktop logins on machines to certain users at certain times of 
the day. This goes some way to addressing the authorisation problems inherent in single sign-on solutions. 

There are some notable differences between the way that Active Directory and UNIX represent users. 
Active Directory uses a binary string SID rather than UID/GID to represent security principals, obviating 
many of the problems caused by the small UID/GID namespace. It also supports nesting of groups, allowing 
administrators to use hierarchical classification of users to better manage authorisation. Prior to Windows 
2003 Server R2 the RFC2307 schema for UNIX attributes was not supported, requiring a one-time (but 
irreversible) update of the Active Directory schema to support UNIX clients. 

In addition, Microsoft made some extensions to the Kerberos protocol in their implementation. Kerberos 
tickets created by Active Directory contain a Privilege Attribute Certificate (PAC) in the Authorisation 
Data field containing group information that can be used for authorisation. Microsoft also provided a 
new password authentication protocol which can be used by administrators to change passwords without 
requiring the user to enter the original password. Lastly, they added a referral mechanism to allow for 
automatic canonicalisation of user names and traversal of cross-domain trusts. Microsoft have further 
enhanced Kerberos in Windows 2003 to support cross-forest authentication and added some new protocols 
to support constrained delegation and the ability to convert an identity from a non- Kerberos domain into 
a Kerberos one. 

Lastly, Microsoft also added support for Kerberos to Internet Explorer (using the SPNEGO [21] / GSS- 
API [8] protocol) which enables use of a user’s desktop credential to authentication to applications without 
requiring a password. This mechanism has also been implemented in Mozilla Firefox and recent versions of 
KDE’s Konqueror. A number of commercial and open source plugins are available for J2EE and Apache 
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servers to implement the server side protocol. SPNEGO is becoming widely used as a mechanism for single 
sign-on to web based applications. 

While Microsoft have designed Active Directory to be compatible with other LDAP implementations 
and MIT Kerberos, for various technical reasons it is not feasible to use these servers as a replacement 
for Active Directory 1 . This leads to the conclusion that for a sizeable number of Windows clients you 
will have to have at least one Active Directory server. Conversely while it is possible for UNIX Kerberos 
clients to support Active Directory, this requires some effort to support, as it requires synchronisation of 
configuration information between Active Directory and individual UNIX machines. This latter problem 
is becoming less of an issue as both MIT and Heimdal improve support for some Active Directory specific 
mechanisms such as referrals and DNS SRV records which reduce the amount of configuration information 
that needs to be stored on the client. 

4.2 Options for integrating with Active Directory 

For most enterprises if you want unified logon across all your systems (Windows and UNIX) you are going 
to have to play nicely with Active Directory. In the following section some of the approaches to integrating 
UNIX with Active Directory are outlined and their relative strengths and weaknesses discussed. 

4.2.1 LDAP authentication to Active Directory 

Because Active Directory supports LDAP, one approach is to install the RFC2307 schema extensions 
and use pamJdap and nssJdap to authenticate to Active Directory. This allows you to leverage the 
replication/scalability infrastructure of Active Directory and does not require unnecessary duplication of 
services. 

Some negative aspects of this approach is that it doesn’t necessarily give you access to Kerberos cre¬ 
dentials to authenticate to other applications (e.g. SPNEGO enabled web applications or SSII). Also, 
as mentioned the tools for managing LDAP identity stores from UNIX are limited meaning that you 
will mostly likely have to rely on the Active Directory tools for user management and custom scripts for 
managing the non-Microsoft parts of the user identity (e.g. Unix UIDs). 

Another alternative is to use a mixture of LDAP and Kerberos to authenticate to Active Directory, 
either by using pam_krb5 or pamJdap with SASL/GSSAPI. This can be complex to setup as administrators 
need to manually create and maintain Active Directory computer objects for UNIX hosts to create host 
keys. 

It is also possible to create a separate MIT/Heimdal KDC and make it part of an Active Directory 
forest by creating an External trust. Clients in Active Directory can access services in the Heimdal KDC 
by using cross- realm authentication and vice versa. However, this approach is not ideal if UNIX clients 
wish to access Windows based services (such as IIS) that use group based authorisation. This requires 
duplication of information by the creation of Foreign Security Principal objects in Active Directory to allow 
them to be members of groups in the Active Directory managed domain. In general this approach is not 
recommended for its complexity. 

LDAP authentication is more expensive than simple Kerberos authentication. To avoid sending plain¬ 
text passwords over the wire you must secure the connection with either SSL/TLS or SASL/GSSAPI. In 
either case this requires a TCP connection to be setup whereas Kerberos can mostly be done over UDP 
(unless you have large PACs that require TCP to be used). SSL negotiations require several round trips 
and expensive Public Key computations. SASL/GSSAPI binds require the client to first obtain Kerberos 
TGTs and service tickets, and then several round trips are performed to negotiate the SASL mechanism 
and authenticate the client. These factors provide additional load on Active Directory servers which may 
reduce the scalability of the solution if there are a large number of UNIX clients. 

4.2.2 Password Synchronisation 

A slightly different approach is to use a different LDAP server for authenticating the UNIX hosts with 
pamddap/nssJdap, and synchronise passwords from Active Directory to the LDAP directory. This ap¬ 
proach is attractive as it provides separation between UNIX and Windows domains. In addition, many 
applications support an LDAP backend for authentication, meaning that this solution can be extended to 
other applications. 

1 Active Directory supports storing a password using “reversible encryption” which will make passwords available. But if 
this is not turned on before user accounts are created then users will have to reenter their passwords. In addition, this is the 
same a storing your password in plaintext and is not recommended. 
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Another advantage is that password synchronisation can be used with legacy systems other than LDAP 
(e.g. RACF or custom applications), enabling the extension of the single sign-on environment to more 
systems. 

One option for password synchronisation is Microsoft’s Identity Integration Server (MIIS), which sup¬ 
ports a number of services (including Sun ONE directory). One advantage of MIIS is uses password filters 
on the Active Directory server to capture password changes and push them to other services, removing the 
need to store plaintext passwords in another directory. An agent runs on the directory server to provide the 
password synchronisation allowing direct storage of password hashes rather than having passwords stored 
in plaintext. 

The main drawback of this approach is it is not generally possible [1] to extract passwords from an 
existing Active Directory store, creating a problem of how you initially provision passwords. In general 
this means requiring all users to change their passwords. In addition, standing up another directory will 
mean duplication of infrastructure for scaling and failover leading to increased hardware and maintenance 
costs. 

In addition, there is the general problem with consistency of ensuring compatibility of password com¬ 
plexity across systems, consistency in the face of cross-site replication. 

4.2.3 SFU 

Services for UNIX (SFU) is a Microsoft product that provides a range of services for integrating Windows 
and UNIX environments. Among other things it includes a number UNIX command line tools, an NFS 
client and server, as well as a NIS server to use with Active Directory. It is possible to integrate UNIX 
clients with Active Directory using SFU by setting up NIS. 

However this approach suffers from the major drawback that as noted, NIS is insecure. It is possible 
to use a hybrid model where Kerberos is used to authenticate to Active Directory using pam_krb5 and 
NIS is used for identity information using nss_nis. However, because NIS does not authenticate servers it 
is still possible for a rogue service to spoof the information (for example providing false UIDs or group 
information) and as such is not recommended. 

SFU also does not use the standard RFC2307 extensions, meaning it may not work well with other 
provisioning tools/systems. It also has no mechanism for detecting UID/GID conflicts when creating UNIX 
users. 


4.2.4 Winbind 

Samba provides the Winbind daemon that authenticates to Windows Domain Controllers using the Win¬ 
dows RPC based Netlogon protocol and retrieves user and group info [1]. It provides NSS and PAM 
modules to fully integrate with the UNIX login process. 

Because Winbind uses the native Windows authentication mechanism it is possible to use the desktop 
login restrictions in Active Directory for UNIX clients, ameliorating the authorisation issue. 

One innovative feature of Winbind is its ability to maps SIDs to UIDs/GIDs automatically. UIDs/GIDs 
are allocated by a first come, first served basis (either using a local database or the IDMAP service which 
may require an external LDAP server). This provides a solution for accessing UID/GID information 
without requiring schema extensions. This allows all users in Active Directory to access UNIX systems 
without requiring specific provisioning of a UID/GID. 

However, this approach could prove problematic for migration scenarios where the administrator wants 
a lot of control over how UIDs are allocated. 

In addition, the Netlogon protocol used by Winbind uses the legacy NTLM authentication protocol for 
authentication which has been shown to be vulnerable to a number of attacks [5]. 

Lastly, like the LDAP solutions, by not making Kerberos credentials available it is not possible to 
leverage Winbind to provide single sign-on to other systems requiring passwords to be re-entered increasing 
the risk of disclosure. 

4.2.5 Vintela Authentication Services (VAS) 

VAS is a commercial product developed by Quest Software. It provides fully integrated PAM and NSS 
modules for authentication with Active Directory that use the Kerberos and LDAP protocols and also 
provide additional support for platforms which don’t support PAM or where PAM is optional (such as 
AIX). Because VAS is designed specifically for Active Directory it is site-aware and also supports the 
desktop login restrictions. Authorisation can be further extended by using a local users.allow/users.deny 
override file. VAS provides a local daemon to support caching for performance and to allow the client 
to operate in ’’disconnected” mode if the Active Directory server is down. VAS also includes a plugin to 
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manage Unix user and group information in the Windows Users and Groups MMC snap-in, as well as a 
command line tool that can perform many management functions such as joining and unjoining machines 
from the domain, and adding, listing and deleting users and groups. 

One major advantage of VAS is that because it is Kerberos based it makes credentials available for 
authentication to other Kerberos aware applications (e.g. OpenSSH, Firefox), extending single sign-on to 
other applications. 

However, like the LDAP solutions VAS relies on RFC2307 extensions to be applied to Active Directory 
servers prior to Windows 2003 R2 (although it has the flexibility to allow configuration of other schema 
extensions such as those used by SFU), a corollary of which is that it also requires you to migrate to a 
unified UID/GID space. 

4.3 Conclusions 

Active Directory is a necessary evil if you need to incorporate Windows clients into your single sign-on 
solution. Fortunately there are a number of solutions for doing this, each with its benefits and weaknesses. 
As noted in section 3.3 it is best if the authentication mechanism is strong, so solutions that favour the 
use of Kerberos are strongly recommended. For a small number of systems, or where the risks of using the 
NTLM protocol are minimal, Winbind can be a useful alternative. Password synchronisation should be 
avoided if at all possible, as it creates both operational issues and security concerns. 


5 Summary 

Single sign-on for UNIX is desirable for security, usability and manageability, but is not without its chal¬ 
lenges. Chief among these is the need to ensure that a strong authentication mechanism is used, and that 
there are sufficient authorisation mechanisms. In addition, there are some issues with migration, namely 
unifying the UID/GID space across disparate machines. 

By using PAM and NSS it is possible to centralise management of UNIX authentication by using one 
or more authentication and identity services. This paper recommends using a mixture of Kerberos and 
LDAP where possible as this couples strong security with flexibility and scalability. 

Lastly, building a single Sign On system for Windows and UNIX means working with Active Directory. 
There are several approaches to solving this problem, but it is recommended that administrators leverage 
the Kerberos and LDAP integration of Active Directory where possible, and avoid solutions based on 
password synchronisation. 
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Introduction 

Configuration management is a topic that is intimately associated with system management, security, and 
fundamentally, computer usage itself. As the ubiquity of computers grows, the raw number of computers 
which need proper configuration and software upgrades grows as well. System administrators have great 
familiarity with the issues of configuration management; most environments have a regular cycle of software 
patching and reconfiguration that must be performed. 

While this task can be onerous, it is absolutely essential; without these regular configuration changes, 
systems can easily become insecure or otherwise non-functional. As tools can make this process faster and 
less error prone, the deployment of configuration management tools can dramatically improve the reliability 
and security of computer networks. 

While it is generally acknowledged that configuration management tools can greatly improve the pro¬ 
cess of system administration, widespread adoption has not generally occurred. This is the most serious 
problem in configuration management. Bcfg2 is by no means alone as a comprehensive option; LCFG and 
Quattor are both comparable. However, none of these tools has seen any serious adoption outside of their 
development environment yet. 

Our experiences deploying Bcfg2 have suggested that complexity is a major aspect of the adoption puz¬ 
zle. All of the systems mentioned above are quite powerful, however, the price of this power is complexity. 
System complexity causes a number of issues. These tools can be foreign or counter-intuitive to users 
unfamiliar with them. Basic administration mechanisms change substantially with each of these tools. We 
have found that bcfg2 users generally start with simpler configuration representations. As their familiarity 
with the tool increases, users grow more willing to accept more complex representations in order to gain 
better functions from the tool. 

Bcfg2 attempts to mitigate complexity issues through the use of generators. Bcfg2 uses generators 
as configuration sources, each of which can have different representations of configuration data. Several 
generators can be used in parallel, each contributing different aspects of the configuration, and each using 
a different configuration representation. This feature allows Bcfg2 to provide a “pay as you go” approach 
to configuration representation complexity. Users can start with simple generators that use a very literal 
representation of configuration data. As users grow more familiar with Bcfg2, and grow to trust it more, 
they can shift their configuration data to more sophisticated representations that allow more reuse and 
recomposition. 

We will discuss several generators and the varieties of configuration representations they use. In each 
case, we will describe the generator’s function and benefits and disadvantages to the configuration format’s 
use. We will also attempt to provide a sense of where each fits into the long term adoption process. 


Related Work 

Several configuration management tools comparable to Bcfg2 exist. LCFG[2] and Quattor[6] are most 
similar to in functionality to Bcfg2. LCFG and Quattor both use parameterized configurations as a basis 
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for system configurations. That is, both of these tools constructs a parameter list per client. Parameters 
consists of keys and associated values. These parameter lists are interpreted by software on clients, resulting 
in configuration changes. Quattor was designed by a group with substantial LCFG experience, so it has a 
similar overall model. The parameter store in Quattor consists of a database, where LCFG uses flat files 
and a preprocessing scheme for client parameter construction. 

CFEngine[4], while being the prevalent configuration management tool, is vastly unlike Bcfg2. CFEngine 
is functionally a domain-specific programming language, tailored to system administration. It is designed 
around an imperative model; users write scripts that alter client configurations into the desired state. On 
the other hand, Bcfg2, LCFG, and Quattor use a declarative model. The user produces a specification for 
client configurations. The tool determines how to best reconfigure clients in light of this specification. 

Much work has been done in the area of configuration tool usability and deployment studies. Remy 
Evard performed a survey of system configuration techniques in 1997 [10]. Paul Anderson has performed 
a more recent survey as a part of the GridWeaver project [1], These surveys have found large numbers of 
tools used for system configuration, many of which are site-specific. This finding highlights the adoption 
problem, as it demonstrates the lack of external adoption of system configuration tools. 

More recently, we have performed a case study in system configuration tool deployment in a large 
group [9]. The deployment process, conducted over a period of months, highlighted the difficulty inherent in 
the adoption of a system configuration tool. Also, a cost analysis of system configuration and administration 
has been conducted. This found a number of interesting issues focused around the methods used in system 
configuration tool use. [7] 

All of this work points at tool adoption as the most serious problem in system configuration at this 
point. Fundamentally, tools will only help the community at large if they can be easily used. 


Tool Adoption 

The adoption of a system configuration tool can be a costly and disruptive process. This high cost is caused 
by several factors. System configuration tools implement functionality that is intimately entangled with 
the daily activities of system administrators. Due to this relationship, tool adoption (of any tool) causes 
large changes to daily administration tasks. 

A central task during this adoption process is the creation of a configuration specification. Different 
tools use different mechanisms to represent this specification. LCFG and Quattor use parameterized spec¬ 
ifications. This mechanism is quite powerful, however, initial setup is quite time consuming. Several other 
systems, including Bcfg2, use more literal representations of configuration, including copies of configuration 
files. Bcfg2 also uses other representations as well. 

We have completed several deployments of Bcfg2, among several different groups of administrators. 
We have found the adoption process to be fraught with other issues as well. Different administrators will 
have different considerations in tool selection. This is largely due to differences in prior experience. As 
each administrator discovers appropriate ways to use the new tool, they find disparate, and, in some cases, 
conflicting mechanisms to achieve the same goals. This issue is the most troubling problem caused by 
expressive, powerful tools. Different mechanisms are developed for many reasons; administrators often 
have different goals, tasks and experiences. Also, as administrators become more proficient with a given 
tool, their usage (and comfort level with tool related complexity) increases. These issues are described in 
much greater detail in another paper [9]. Suffice it to say that this process can be quite intense and costly. 


Bcfg2 

Bcfg2[8] was originally designed as a system configuration tool research vehicle. Over the last three years, 
the basic design principles have proven themselves in several environments. A major revision was completed 
in the last year, resulting in a production-quality tool. Bcfg2 is now deployed in several environments, and 
has been publicly released [3]. 

Architecture 

Bcfg2 is designed as a client/server application. The client is responsible for fetching a configuration de¬ 
scription from the server, inventorying local client state and committing appropriate configuration changes. 
The server is responsible for marshalling the overall configuration specification into a client-specific config¬ 
uration description. 
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Client 

The Bcfg2 client is run as a normal program on each client. The client configuration process consists of 
three steps. It connects to the server, and fetches a series of probes. These probes are executed, and the 
results are uploaded to the server. Probes detect local contributions to system configuration and can be 
used to discover hardware inventories or any other locally canonical data. 

After the probe interaction, the client fetches a literal configuration description from the server. This 
description consists of dependent and independent clauses of configuration entries. Entries can have one 
of five basic types: ConfigFile, Package, Service, Symlink, and Directory. Dependent clauses, or bundles, 
contain a set of entries that have installation-time interdependencies. Bundles generally correspond to 
services, their configuration files, and associated software packages. 

Once the client has downloaded the configuration description, it inventories itself. It compares this 
with all configuration entries in the description. Any non-conforming entries are flagged for correction. It 
then checks for configuration entries that aren’t included in the description. This process is called two-way 
verification. It provides fairly rigorous configuration verification. 

Once the inventory step has completed, the client corrects any misconfigurations. This process loops 
correcting errors until no more progress can be made. It also provides automatic dependency handling. At 
the end of this stage, all reconfiguration that can be made has been done. That is, with no changes, an 
additional client execution will not result in any additional actions. 

Upon update completion, the client produces a message containing a number of statistics including 
overall state, failing configuration entries, modified configuration entries, and extra configuration entries. 
This message is sent to the server where it can be used to create system summaries. 

In our experience, client details only impact adoption insofar as client reliability and result exposure 
are concerned. Most all complicated adoption issues occur as a result of server-side design decisions. 

Server 

The Bcfg2 server is responsible for rendering the overall configuration specification into a per-client con¬ 
figuration description, managing client settings (such as base image, profile, and other metadata), and 
maintaining client statistics. The system is designed around a central specification. Administrators de¬ 
scribe the intended goal configuration in this specification. Clients start in some state, not necessarily 
identical to the goal state. As client nodes run Bcfg2, discrepancies between clients and their desired con¬ 
figuration are individually corrected. These changes and the goal states are tracked in the client statistics. 
Through the use of both the specification and client statistics, three important pieces of information can 
be derived: the desired state, non-conforming clients, and a list of ways those clients are misconfigured. 
Using this information, administrators can determine all client states using only server-side information at 
any time. 

The role played by the server is obvious during all client configuration steps, with the exception of 
the client configuration description creation process. This process consists of the following steps. First, 
the server locates metadata for the client requesting a configuration. This data is used to construct the 
abstract configuration. The abstract configuration is a skeleton configuration that contains an inventory of 
all configuration entries needed for the client configuration, but without any literal contents. For example, 
“ConfigFile” entries in the abstract configuration will have a filename but no file contents or permission 
information associated this it. The abstract configuration contains all of the entries that will appear in the 
complete, literal configuration. This step is used to map out bundles and create structure in the abstract 
configuration. 

Once the abstract configuration has been constructed, literal data must be bound into each entry. The 
Bcfg2 server uses a set of generators for this task. Generators are server side loadable modules. They are 
enabled upon server startup, and register ability to provide literal configuration information about partic¬ 
ular configuration entries. For example, a generator may register the ability to provide literal information 
for the configuration file “/etc/passwd”. When the server needs to bind data into a configuration element, 
it locates the generator that can service for that element, and calls it. The generator can then execute 
arbitrary logic to determine the correct literal values for this entry on the given client. 

The use of generators in the Bcfg2 server creates a number of interesting features. Most importantly, 
arbitrary representations can be used as specifications. This makes Bcfg2 an ideal testbed for specification 
languages. Second, arbitrary logic can be employed in the process of literal configuration construction. This 
means that any scheme imaginable can be used to construct configuration from a specification. Randomness 
and a variety of other programmatic techniques can be employed in this process. More importantly, actions 
can be associated with the configuration process. 

A number of issues in the adoption process are centered around specification language. In the case 
of Bcfg2, we have found it useful to have multiple ways to specify similar configurations. This provides 
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multiple models that can be used for different administrators as appropriate. 

In general, administrators’ trust in system configuration tools only grows with experience. Initially, 
administrators neither trust or have a deep understanding of any new tool. Common sense suggests that 
simple configurations will cause less problems than complex ones, so new users tend to create literal and 
straightforward configuration specifications. 

The model provided by Bcfg2 allows administrators to work with a specification language as literal or 
abstract as required by the problem and the administrator’s familiarity and comfort level. 


Generators and Specification Languages 

Due to the use of several different generators in the same Bcfg2 deployment, different languages with 
vastly different semantics are frequently used concurrently. We will describe several generators, and their 
associated specification languages. This will provide some examples of how Bcfg2 can use literal and 
symbolic specifications. 

The use of client metadata is prevalent throughout all generators. The metadata for a client consists 
of its hostname, image, profile, set of classes, set of bundles, and set of attributes. In general, specification 
fragments will apply to some subset of clients based on one of these characteristics. 

Each generator consists of a loadable module and a filesystem repository. The repository contains 
generator specific configuration specification. 

Cfg 

Cfg is a generator that implements a literal configuration file repository. For each configuration file 
served, a relative path in the filesystem repository is created. For example, for a configuration file like 
/etc/Xll/xorg. conf, a directory corresponding to the path is created, in this case ./etc/Xll/xorg. conf/. 
Literal copies of configuration files are placed in this directory. Each file in this directory applies to some 
subset of clients, based on metadata. Applicability is determined based on the filename. All filenames start 
with the basename of the configuration file. If no suffix is specified, then the file applies globally, at the 
lowest priority. More specific files will have a suffix that contains a metadata type (like hostname, class, 
bundle, or image), the name of a group of that type, and a priority used in case of ties. 

This generator provides a very literal and predictable representation of configuration. What you see is 
precisely what you get. This makes this generator one of the default set of generators enabled in Bcfg2 
installations. 


SSHbase 

SSHbase is a ssh key management system. It maintains a repository of ssh public and private keys and 
constructs a comprehensive sshJknownJiosts file. It functions entirely automatically; new keys are gener¬ 
ated when one is requested for an unknown host. At this point, the sshJmown_hosts file is updated for 
all clients. 

The repository language used by this generator consists of a directory containing public and private keys 
for all clients. This system ensures two basic properties. First, client keys persist beyond client rebuilds. 
Second, client keys can be centrally revoked, in case of a system compromise. 

The files in this directory are structured like host specific files in the Cf g repository. Each file consists 
of the key file basename followed by “.H_” and the client’s hostname. 


TCheetah 

TCheetah is a generator based on the Cheetah templating language[5]. Configuration files are generated 
by instantiating a template populated with values from an XML document. These XML documents are 
contained in the TCheetah repository and contain two basic types: a keyval type, and a list type. List 
types can contain other list types or keyvals. 

The TCheetah generator is quite powerful, particularly when compared with the previous two generators 
described. At the same time, this generator is much more complex, so its use typically occurs after 
administrators are comfortable with Bcfg2 overall. 

In our environment, we used Bcfg2 for nearly a year before starting to use TCheetah. It is used to 
automatically build DHCP, DNS, and NIS files from the same canonical host data. Our current system 
could easily be extended to interface with LDAP systems as well. 
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This generator provides a powerful model that can be used to generate configuration files in multiple 
formats based on the same canonical data. This scheme is very similar to ones provided by LCFG and 
Quattor, and has proven itself quite capable. 

ServiceMgr 

The service manager generator provides service activation and deactivation information for clients. Its 
specification consists of a single XML file that contains metadata class based service information. This 
generator is a good example of a group of several generators that use a metadata class scoped XML file 
for configuration specification. 

Other Generators 

Several other generators exist and are in development. These provide several other capabilities and spec¬ 
ification representations. Of the more complex ones, many could alternatively be implemented as a set 
of TCheetah templates. User interface issues are generally the motivating factor for alternative powerful 
generators. We have found that our administrators like domain specific languages in some cases. We have 
added a domain specific language for account and user access information, and one for Webserver virtual 
host layout. Generators are easy to write, and can be added whenever it appears that another configuration 
representation may be useful. 

Similarly, generators have a variety of other uses as well. They are well suited to tracking external data 
in local configuration files, as in the case of tracking changes made globally to DNS. Generators are also 
useful for encoding administrative processes. 


Results 

The ability to choose (or indeed create) representations for configuration specification based on the individ¬ 
ual situation has yielded a great number of benefits both during and after the adoption process. A number 
of tradeoffs are implicit in this decision. Depending on the situation, and the administrator’s comfort level 
with the tool, a simple solution may be the most desirable. As time goes on, it may be desirable to migrate 
to a more complicated representation that provides more functionality. 

This feature is provides a substantial departure from other system configuration tools. Bcfg2 provides 
the ability to migrate from a simple representation to a more sophisticated one on a configuration file by file 
basis. Usually, tools provide a single mechanism for specification. The ability to use many representations 
allows administrators to choose the deliberately take on cost where they think it will be valuable. 

During our deployments, we have found that this ability makes administrators far more comfortable with 
the tool. In each case, administrators started with a simple, literal representation of their configuration. 
As time goes on, administrators are willing to assume more complexity in particular areas where there 
configuration needs are complicated. 

We have found that these areas differ radically from environment to environment. In our cluster 
environments, our hardware configuration is static; hence, we are able to use a literal configuration with no 
problems. In our workstation environment, hardware is largely varied. This hardware also changes quite 
frequently. For this reason, we have adopted a more complicated system that automatically tracks client’s 
hardware inventory and generates a proper set of configuration files for that hardware. This system is 
completely unnecessary for a largely static system like our clusters, and takes more time to maintain and 
tune. It is also harder to modify or explain to new administrators. 

Conversely, user access to nodes in our clusters change frequently, so we are willing to accept more 
complexity in the system that manages system authentication data. Users are only granted access on 
nodes where their jobs are currently running. On our workstation environment, user access changes only 
when new users are added or old accounts are removed. 

System administration is rife with these sorts of decisions. Being able to decide when it is worthwhile to 
assume additional complexity leads to systems that are as simple as is reasonable for a given environment. 

Conclusion and Future Work 

Tool complexity is a key issue preventing widespread deployment of system configuration tools. While many 
capable tools exist, the costs of deployment are too high for many environments to bear. Our approach of 
allowing representations of varying complexity has been demonstrated to improve the situation, particularly 
during the adoption process. 
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This technique has also provided a good migration path for our administration after initial deployment. 
It provides a good mechanism for administrators to tackle their complicated system configuration problems 
without incurring overhead where none is needed. 

That said, much work remains to be done. Tool adoption is still much too difficult for successful 
widespread adoption. The adoption process could be vastly improved. Automatic specification acquisition 
would go a long way in helping administrators to try tools out. Better incremental adoption techniques 
would allow slow migration of environments onto system configuration tools. 

Motivation is another issue that must be tackled. It is imperative that better system configuration 
techniques be adopted. However, short term compelling reasons are needed to justify up-front adoption 
costs. Tools that can be adopted incrementally will help with this issue; smaller scale initial deployments 
can begin providing benefits for parts of the environment before a complete specification is created. This 
also has the effect of lowering the cost of entry for these tools. 

Bcfg2 will continue to be a testing ground for ideas relating to system configuration. We plan to add 
a facility for automatic change detection and integration. This will allow easy maintenance of already 
configured systems, and will ease the reconfiguration process. We also plan to create a tool that will create 
an initial configuration specification. This will help new users to try out Bcfg2. At our site, we plan to 
deploy Bcfg2 in a number of new environments. This will undoubtedly provide valuable information about 
adoption issues faced by new users. 
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Introduction 

The FreeBSD Ports system is one of the main selling points of FreeBSD and is a major achievement. In this 
paper we will take a light trip through the ports internals touching on some useful utilities and commands. 
Please note, however, that while I will be mentioning utilities and some of their more useful command line 
switches I won’t be regurgitating whole man pages. 


In the beginning — Packages 

Pretty much every unix or unix-like operating system has a package management system. In this we 
mean a method to bundle and install binary distributions of third party applications. FreeBSD has the 
pkg.add/pkg-info/pkg.delete group of tools which do pretty much the same as everyone else’s package 
management tools including fetching the packages via the net and resolving simple dependancies. Since 
FreeBSD’s Ports system is integrated with the package management system lets take a quick look at how 
it works. 

What is a Package? 

A FreeBSD package is a compressed tar archive that places ready to run binaries and supporting files into 
their correct places in the filesystem. It also contains some extra housekeeping information which is stored 
in a special place in the filesystem (/var/db/pkg) where it is used to keep track of installed packages and 
how to delete them. 

Fetch me a Package 

You can obtain packages either off your CD-ROM install media, or via downloading them using the Internet. 
In both cases the pkg.add utility can automate that for you. This can be very useful if you are installing 
something that has a lot of dependencies as the tool will recursively fetch them for you. 

Add me a package 

The pkg.add command takes the compressed archive and installs it. It registers the installation in the 
package database in /var/db/pkg so you can find it with the pkgdnfo command. There are three options 
you will mainly use. They are “-v” to make the program verbose, “-f” to force an install, even if there are 
unsatisfied dependencies or it is already installed, and “-r” which will recursively fetch the package and 
any required dependencies via the net. 

Tell me about a package 

The pkgjnfo command tells you about what packages are installed on your system. This seems bleedingly 
obvious, and I guess it is however since the Ports system hooks into the same package database this 
command also tells you what ports you have installed. In fact, once installed, there is little difference 
between a port or a package. You will use pkgjnfo a lot. You can use pkgjnfo by itself to generate a list 
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of installed packages and then use the “-L” option to see what files a specific installed package/port has 
installed. 

Go away you horrible little package 

It doesn’t then take much imagination to work out that pkg_delete removes installed packages from your 
system. It grabs the list of installed files for the package from the package database in /var/db/pkg 
and deletes them, cleaning up directories if required. Since both packages and ports look the same once 
installed, you can use pkg.delete to remove either of them as required. 


So what is this package database anyway? 

Well, calling it a “database” is a little grandiose as it is actually just an intelligently laid out directory 
structure holding a few informative files but it is a vital part of the whole packages/ports thing so we’ll 
look at it a bit more closely. 

It sits in /var/db/pkg and is a group of subdirectories, one for each installed package. Each subdirectory 
is named for the package with the package version number tacked on the end, for example the directory 
holding information for Xorg Clients v6.8.2 is named “xorg-clients-6.8.2”. 

Inside each subdirectory are a number of files. Most are reasonably obvious as to what they are so I 
won’t go into them, however +CONTENTS is probably the most informative. It contains, as you would 
expect, the list of files installed by the package, however it also contains dependencies, uninstall information 
and the MD5 checksum of every installed file so it can be sure it is deleting the right one when you use 
pkg.delete. 

In most situations the package database is self managing. You will only need to dive in there if something 
is seriously screwed. In most cases you’ll be better off using “pkg-delete -f” and then re-adding the package 
than trying to modify stuff in there. 


Alright, that’s enough about packages, what about ports? 

A port is a skeleton providing information about a ported application or utility as well as modifications to 
the application source code and configuration information to let it compile and install correctly. It does 
not contain the application source code itself. This is important so lets repeat it, the port itself does NOT 
contain the source code to the application or utility. It contains instructions on where to get it and what to 
do with the source code once you download it so that it compiles and installs correctly. Also worth noting 
here is that the port system actually triggers the application’s own build mechanism after setting up the 
environment and applying FreeBSD specific modifications rather than supplanting it. 

The build step is the major difference between packages and ports. In a package the application is 
pre-compiled and collated ready for installation. Installing a port involves downloading and compiling the 
source code to generate the application before you get to do the actual putting-binaries-into-directories 
thing. This is time consuming and considerably more complex than just downloading and installing a 
package. 


So, you’re now asking yourself, why do we bother? 

There are several good reasons why ports are preferred over packages by more experienced FreeBSD people. 
Firstly compiling the port yourself allows you to specify compile time options. Many of the ports can be 
built in different ways depending on what you want to do with it. The ports system contains a mechanism 
for offering those options to you and maintaining them between compiles. 

The second good reason is a bit more subtle. Modern software is complex and often relies on a number 
of other applications or utilities for functionality and correct operation. Each piece of software is usually 
developed independently so changing a single piece of software that is being relied upon by something else 
can cause major problems. Building an application from a port means the application is built based on 
the pre- requisites currently installed on YOUR system rather than the ones on the package build cluster 
at FreeBSD.org. This tends to make the system a little more stable. The portupgrade toolset is a major 
help in this as well as it lets you upgrade both applications and their dependencies in one go. We’ll look 
at this toolset later. 

The third reason has more to do with how you manage your whole system. By default the package 
management tools select packages for installation depending upon what release of FreeBSD you are running. 
For example, if you are running 5.3-RELEASE then you will only have packages presented to you that were 
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built when 5.3-RELEASE was released, even though there are later packages available to those running 
5.4-RELEASE. You could try manually fetching packages from 5.4-RELEASE and installing them on your 
5.3- RELEASE system however it is likely they won’t work due to major changes between the releases. 
If you are using the ports system though you can use a current ports tree on 5.3-RELEASE, or even 
4.9-RELEASE and have an excellent chance of installing a working application. 


Ok, you’ve convinced me! How do I get the ports tree? 

There are three ways to obtain an up-to-date ports tree. They are HTTP, CTM and cvsup. 

The easiest is to grab a 25Mb gzipped tar archive of the entire tree (13,307 ports) via HTTP from 
http://www.freebsd.org/ports/. The hardest is probably via CTM and the recommended method 
is via CVSup. In both CTM and CVSup you maintain a local ports tree and download updates however 
the difference is that CTM delivers the updates via email, and CVSup delivers them in real time. CTM 
is really only useful for people with very limited internet connectivity such as being stuck behind a hostile 
firewall and I would personally recommend that you should try very hard to make CVSup work before 
trying one of the alternatives, and CVSup is usually very easy to get working. 

In fact, this is how easy to make it work; 

1. Copy /usr/share/examples/cvsup/ports-supfile to /usr/local/etc/ so that future updates don’t clob¬ 
ber your working copy. This is the configuration file for cvsup that tells it what to get and where to 
get it. Have a good look in that source directory as cvsup is also the best way to get the sources to 
update your system itself and example configurations for that are there. 

2. Edit /usr/local/etc/ports-supfile and change the line “CHANGE_THIS.FreeBSD.org” to point to 
your nearest cvsup server. See the FreeBSD handbook for the list. 

3. Install cvsup with either “pkg_add -vr cvsup” or “pkg_add -vr cvsup_without_gui”. You can use the 
second one on hosts that don’t have XI1 installed. 

4. Type “cvsup /usr/local/etc/ports-supfile” and if you have the gui version click on “start”. 

5. Change directory to /usr/ports and type “make fetchindex” (this voodoo will be explained later). 

Woohoo! You now have a current ports tree! Oh, and all of the above should be done as root. 

The first time you do it will take a while but then first times are usually a bit awkward so don’t panic. 
After that it will be reasonably quick depending on how long it’s been since you updated, how fast your 
connection is and how busy the ports gods have been. 

Ok! I’ve done all of that! Um, what are all these files and directories? 

That is the ports tree! Ports are grouped into categories to help you find them. A port can be in 
multiple categories however it must have a primary category that corresponds to a directory in the tree. 
A secondary category will be a virtual one used only to group ports to aid in searching and not reflected 
in the directory structure. 

Also under /usr/ports/ itself are some important files and a very important directory. The most 
important file is “UPDATING”. This is where ports maintainers document any gotchas in upgrading their 
ports. Read this EVERY TIME you cvsup. It will save you. Also worth checking out is the “CHANGES” 
file and of course peep at the “README” file before you get too far along. 

The very important directory, “Mk/”, contains the guts of the ports build system. The FreeBSD ports 
system is powered by BSD “make”. This directory contains the “make” magic that binds the whole thing 
together and if you want to see how it all works, peek in here. In fact it would be a good idea to have 
a good long rummage through here as this is where you will find the definitive list of what environment 
variables you can set to make certain things happen during the build and install. Very geeky but highly 
recommended. 

The last important file in the /usr/ports directory is “INDEX-5” (just “INDEX” on FreeBSD 4.x). 
This, as you would expect, is an index listing every port in the tree. It includes their names, descriptions, 
origin in the ports tree, dependencies and install prefix (under what directory the port will install). This 
file is generated by extracting the information from every port so can take a long time to build. In the 
past this file was retrieved as part of the ports CVSup however that version of the file was frequently very 
old and incomplete. These days a fresh version of the file is built once per day and should be fetched by 
using the “make fetchindex” command after you have updated the ports tree. You can generate your own 
using the “make index” command but it takes a long time (1 hour and 12 minutes on my 600Mhz Celeron 
box) so go fetch a coffee while it does the work. 

I have the tree but the gnome2 directory is only 14Kb, that’s a bit small isn’t it? 
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For all of Gnome 2, yes. The source files for Gnome 2.10 on my system are about 145Mb. What you 
have in each port’s directory is a skeleton that tells the ports system how to fetch, patch, build and install 
the port. This is why over 13,000 ports only take up 25Mb. We’ll take a closer look at how this works in 
a moment, but for now lets look at the contents of an individual port directory. 

A port directory can contain the following files and directories; 

• Makefile 

• pkg-desc 

• pkg-plist 

• distinfo 

• files/ (a directory) 

and a few more port specific ones that I won’t bother with here. 

These files are the meat of the whole process, but before we dive into them we need to note that the 
ports system is still tied heavily into the older package system. These files have their origins in the metadata 
included with packages and in most cases are used by both systems for exactly the same purposes. It goes 
even further than that though as FreeBSD packages are now automatically built from this ports tree and 
so these same files are used in both the ports and packages systems. When creating a new port, the port 
author needs to remember that their work will generate both a ports skeleton in the tree and a package 
in the packages system and they will need to accommodate the differences therein. So, remembering that, 
lets dive right in! 

The “Makefile” is the guiding hand that controls the whole ports process. It contains all the information 
required to control the build of the port including dependencies, source location and where to put it. Given 
that this file is so important, lets dissect one in detail. 

Let’s take a look at /usr/ports/comms/gmfsk. 

From the “pkg-descr” file; 

gMFSK is a multi-mode soundcard terminal program for HF amateur 
communications. Originally the program was written for compatibility 
with the IZ8BLY Stream program in MFSK16 mode. Currently the program 
supports the following amateur digital communications modes: MFSK16, 

MFSK8, RTTY, THROB, PSK31, PSK63, MT63 and FELDHELL. 

From the “Makefile”; 

# New ports collection makefile for: gmfsk 

# Date created: 29th May 2003 

# Whom: Carl Makin <carl@stagecraft.cx> 

# 

# $FreeBSD: ports/comms/gmfsk/Makefile,v 1.8 2005/03/12 10:54:17 marcus Exp 
$ 

# 

P0RTNAME= gmfsk 

P0RTVERSI0N= 0.6 

P0RTREVISI0N= 2 

CATEGORIES^ comms audio 

MASTER_SITES= http://gmfsk.connect.fi/ 

MAINTAINER= carlSstagecraft.cx 

C0MMENT= The Gnome MFSK terminal program 

LIB_DEPENDS= fftw.2:${P0RTSDIR}/math/fftw 

GNU_C0NFIGURE= yes 

C0NFIGURE_ENV= LIBS="-L${L0CALBASE}/lib" \ 

CPPFLAGS="-I${L0CALBASE>/include" 

USE_GMAKE= yes 

USE_GN0ME= libgnomeui gnomehack gnomeprefix 
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USE_REINPLACE= yes 
USE_X_PREFIX= yes 

OPTIONS 3 HAMLIB "Enable HAMLIB Support" On 
.include <bsd.port.pre,mk> 

.if !defined(WITHOUT.HAMLIB) 

LIB_DEPENDS+= hamlib:${PORTSDIR}/comms/hamlib 

CONFIGURE_ARGS+= —enable-hamlib 

CONFIGURE_ENV+= PKG_CONFIG_PATH=${LOCALBASE}/lib/pkgconfig 
.endif 

post-patch: 

@${REINPLACE_CMD} -e 

’ s|[$$][(]localstatedir[)]/lib/scrollkeeperI${SCROLLKEEPER_DIR}Ig’ \ 

${WRKSRC]-/omf .make ${WRKSRC}/help/gmfsk/C/Makefile . in 

post-install: 

@${CAT} pkg-message 

.include <bsd.port.post.mk> 

Let’s look at each part in turn; 

P0RTNAME= gmfsk 

This tells us that this Makefile relates to gmfsk. 

PORTVERSI0N= 0.6 

It is version 0.6, which is usually the vendor or author’s version number. 

PORTREVISION 3 2 

That it is the 2nd revision to the port skeleton for this version of the program. This is used to indicate 
to the ports system that something in the port skeleton itself has changed rather than the source code of 
the application. 

CATEGORIES 3 comms audio 

This port is primarily in the “comms” category, but should also be listed in the “audio” category. Both 
of these categories are “real” ones in that they have directories under /usr/ports however gmfsk itself 
will only have a directory under “comms” and not “audio”. It will, however, be listed if you went to 
http://www.freebsd.org/ports/ and viewed all the ports under the “audio” category. 

MASTER_SITES= http://gmfsk.connect.fi/ 

This is where to get the source code for the program. If the ports system can’t retrieve the source from 
here then it will try the master repository at ftp.freebsd.org where most sources files are also archived. 

MAINTAINER= carl@stagecraft.cx 

COMMENT 3 The Gnome MFSK terminal program 

The MAINTAINER is listed against the port as who you should first contact in case of a problem with 
the port. The COMMENT means what it says! 

LIB_DEPENDS= fftw.2:${PORTSDIR>/math/fftw 

This specifies what other ports need to be installed before this port can successfully install. It also 
specifies how to work out it the port is already installed. Pre-requisites do not have to be installed by the 
ports system to be detected and used. When making sure something is already installed the port system 
can look for the existence of various files. In this case it looks for “libfftw.so.2” in the standard library 
paths. If it can’t find it, then it will trigger an install of the “/usr/ports/math/fftw” port. 
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GNU_CONFIGURE= yes 

The port uses the GNU Configure system. This will cause the build to call “configure” with the options 
listed below after it unpacks and patches the source. 

CONFIGURE_ENV= LIBS="-L${LOCALBASE}/lib" \ 

CPPFLAGS=" -I${LOCALBASE}/include " 

Environment variables that need to exist during the “configure” step. In this case they are to work 
around a bug in autoconf v2.53. 

USE_GMAKE= yes 

Like most programs ported across from Linux, gmfsk uses GNU Make rather than BSD Make. This 
causes the ports system to use GNU Make when invoking the application’s build system. 

USE_GN0ME= libgnomeui gnomehack gnomeprefix 

Some significant suites of applications have special triggers within the ports system. You can see which 
ones by looking at the .mk files in /usr/ports/Mk. Gnome is one of these. This line tells the build system 
that aside from the LIBJDEPENDS dependencies above, this application relies on the Gnome libraries 
listed. This is really nice as it doesn’t matter exactly what those Gnome libraries are, the Gnome porting 
gods take care of that for you. This keeps the Makefile a lot simpler and meant this port didn’t need major 
modification during the Gnome 2.6->2.8 or 2.8->2.10 upgrades. In fact the only modification made was 
that the PORTREVISION number was bumped to allow for an easier upgrade between Gnome versions. 

USE_REINPLACE= yes 

This tells the ports system to use the “inplace” version of “sed”. This version edits a file in place rather 
than the usual unix method of piping it through sed and creating a new file. Sed is used below to edit a 
couple of files to better fit them into the FreeBSD view of the world. 

USE_X_PREFIX= yes 

This causes the ports system to install gmfsk into /usr/XllR6 rather than /usr/local (which is the 
default). This hooks into the “GNU-CONFIGURE” option above so causes the ports system to call GNU 
Configure with a prefix=/usr/XHR6” parameter. 

0PTI0NS= HAMLIB "Enable HAMLIB Support" On 

This allows you to specify options to the build process so you can easily customise the build without 
manually setting environment variables or hacking the Makefile. These options are stored in 
“/var/db/ports/<portname- version>” so will be automatically applied each time you build that port. In 
this case it sets the “HAMLIB” environment variable to “On” by default and specifies a prompt for the 
user which will be displayed when they first install the port or later if they call “make config”. 

.include Cbsd.port .pre .nik> 

This delves a little more deeply into the ports voodoo. Normally as part of a port build the file 
“/usr/ports/Mk/bsd.port.mk” is included. This file provides most of the background make magic that does 
all the work. However, sometimes you need to change things that are both set and used in “bsd.port.mk”. 
The “bsd.port.pre.mk” and matching “bsd.port.post.mk” mechanism lets you fiddle with those things. In 
this case we use it to let us add dependencies, configure arguments and environment variables based on 
what options the user has requested, as the next bit demonstrates. 

.if !defined(WITHOUT.HAMLIB) 

LIB_DEPENDS+= hamlib:${P0RTSDIR}/comms/hamlib 
CONFIGURE.ARGS+= —enable-hamlib 

CONFIGURE_ENV+= PKG_CONFIG_PATH=${LOCALBASE}/lib/pkgconfig 
.endif 

Here, if the user has selected to build the port with the “Hamlib” option, then this adds “/usr/ports/- 
comms/hamlib” as a dependency of gmfsk and enables the knob in configure. 
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post-patch: 

@${REINPLACE_CMD> -e 

’sI[$$][Qlocalstatedir[)]/lib/scrollkeeper|${SCROLLKEEPER_DIR}|g ) \ 

${WRKSRC}/omf.make ${WRKSRC}/help/gmfsk/C/Makefile.in 

As part of the build process you can add steps into each build phase. This “post-patch” label causes 
the ports system to call these commands immediately after it has completed applying any needed patches 
and before it runs the application’s configure script. In this case it is doing something specific to Gnome 
which makes the application’s own build system put the application’s help files in the right place. 

post-install: 

@${CAT} pkg-message 

Here is another step, invoked after the install phase, which displays the file “pkg-message” to the user. 
The “pkg-message” file is actually a leftover from the package management system. If this file is present 
in a package then it is automatically presented to the user. This snippet mimics that action for the ports 
user. 

.include <bsd.port.post,mk> 

This is explained above. 

Ok, lets look at the next file in the “/usr/ports/comms/gmfsk” directory, “pkg-plist”. 

This file is necessary in both the ports and packages system. It contains a list of every file installed by 
the port as well as listing what directories should be deleted when uninstalling the port or package. It also 
contains commands that will be executed when installing, or uninstalling a package. These “exec” and 
“unexec” commands are only executed by the package system and are ignored by the ports system. 

The next file, “pkg-desc” contains a basic description of the package and the last file that we’ll look at 
is “distinfo”. This file contains an MD5 sum and size of the source archive enabling the port system to 
check that it has downloaded the correct file. 

Lastly, there is the “files” directory. This contains patches and other files that are required to modify 
the application source so that it compiles correctly under FreeBSD. The most common files are patches, in 
unified diff format, named like “patch-<filename>” so they can be easily found and automatically applied 
by the ports system. 

Right! That is what makes up an individual port. So how do we install one? 

This bit is almost too easy. At its simplest you cd to the port’s directory and type “make install”. 
Yep, that’s it. The ports system will fetch the source, fetch and build dependencies, extract the source, 
configure, build and install the port in one go. The only thing it leaves you to do is clean up after it with 
a “make clean” command. 

There is, however, a lot going on behind the scenes and the port system lets you get at each phase of 
the install as you require. Remember that the ports system is based on BSD Make. When you run make 
you can specify a “target”. This “target” equates to an option inside the Makefiles (and .mk files which are 
included automatically) which allow you excellent control over the whole ports system. Here is a section 
from the excellent “ports(7)” man page by David O’Brien; 

The following targets will be run automatically by each proceeding target in order. That is, build will 
be run (if necessary) by install, and so on all the way to fetch. Usually, you will only use the install target. 

config 

Configure OPTIONS for this port using dialog(l). 


fetch 

Fetch all of the files needed to build this port. 


checksum 

Verify that the fetched distfile’s checksum matches the one the port 
was tested against. 


depends 

Install (or compile if only compilation is necessary) any dependencies 
of the current port. 


extract 

Expand the distfile into a work directory. 
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patch 

Apply any patches that are necessary for the port, 
configure 

Configure the port. 

build 

Build the port. This is the same as calling the all target. 
install 

Install the port and register it with the package system. This is all 

you really need to do. 

There are many other targets available and listed in the ports(7) man page which we won’t go into here 
but there are a couple that are very useful that we will take a quick peek at. 

The first is “make clean”. This removes the working directories of the current port and all dependencies 
in one go from the ports tree. It can take a little while if there are a lot of dependencies. 

The last target is “make deinstall”. This is the functional equivalent to “pkg-delete” but is preferred for 
applications you have installed via ports. It uninstalls the application off the system, removing all installed 
files, performing cleanups where possible and removing the metadata from the packages database. 

That basically covers the ports system itself. There are a lot more options that we haven’t covered but 
they aren’t commonly needed and the FreeBSD handbook and ports man pages cover them well. As a last 
resort you can browse the .mk files in “/usr/ports/Mk” and see how it all hangs together. 

So now that , we understand the basics, lets move on to the next stage of our journey through the 
FreeBSD ports system. Lets take a look at “portupgrade”. 

Portupgrade makes an already reasonably simple and comprehensive ports system even simpler and 
more comprehensive. Ports and packages are great for installing and deleting applications, but they arn’t 
that great at upgrading them. Especially if you have a heap of ports to do at the same time, such as 
upgrading XOrg or libjpeg. In fact the libjpeg case is the most interesting. There are a heap of applications 
that rely on libjpeg. With ports or packages, if you needed to upgrade libjpeg you would have to manually 
track down those applications and upgrade them, in the correct sequence. Portupgrade automates all of 
that for you. With a simple command (and a fair amount of time) you can do things like “upgrade libjpeg 
and EVERYTHING that depends on it”. What’s more it will track dependencies of dependencies and 
perform the upgrades in the correct order to make sure everything is upgraded correctly. 

Portupgrade is, itself a port. You install it for the first time via the standard “cd /usr/ports/sysutils/- 
portupgrade ; make install” sequence as you would any other port. 

Portupgrade offers a number of utilities including; 

• portupgrade 

• portsclean 

• pkg_which (and pkgdb) 

There are more, but these are the main ones so lets take a look at them in that order. 

Portupgrade is the workhorse application of the lot. It performs upgrades and installations as requested. 
If invoked with a port name as an argument it will check the version in the package database against the 
version in the ports directory and upgrade it if the port is newer. With a couple of command line switches 
you can tell it to upgrade not only a specific port but all other ports that this port depends upon, or 
even all ports that depend on this port. You can tell it to upgrade every installed port on the system and 
even force the install if the versions numbers already match. It may also be invoked as “portinstall” which 
is functionally the same as using the “-N” switch which automatically installs a port if it isn’t already 
installed. 

Portsclean automates tidying up around the place. It can purge source archives from the distribution 
store area (/usr/ports/distfiles) that no longer apply to the current ports tree. It can also recurse through 
the ports tree deleting work directories and cleaning up after failed installs. 

Pkgjwhich tells you what port/package a particular file came from. You can give it a full path to a file 
and it will search the package database and tell you which package or port installed it. It is also used to 
maintain the package registry database which is used to speed up portupgrade operations. 

That’s it for Portupgrade! There doesn’t seem to be a lot to it, but it will save you hours of effort and 
make it significantly easier to keep your system up to date. 
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The last thing we will take a quick peek at is “portaudit”. This integrates with the port make mechanism 
to check each port as you install it against a vulnerability database. The database is updated nightly via 
ftp. If the port has a listed vulnerability then it will fail the install. Portaudit can also be run against 
currently installed packages and ports to generate a list of vulnerabilities. In that case it doesn’t need a 
ports tree. 

Well, that wraps up this light trip through the FreeBSD ports system. If you would like to know more 
then here is some recommended reading. 

• http://www.freebsd.org/ports - A web browsable version of the FreeBSD ports tree. 

• http://www.freebsd.org/handbook/ - The FreeBSD handbook. 

• http://www.vuxml.org/ - The Vulnerability and eXposure Markup Language website. 

• http://www.freshports.org/ - The latest FreeBSD ports news and information. 
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Building a Simple GIS with PHP and 
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Abstract: 

Everybody uses maps, and most people have used a web based map. Using the relatively new spatial 
extensions in MySQL, you can build a Geographical Information System to display a dynamic set of 
locations on a zoomable, self centering map. Much of the work is done for you by the original cartographer, 
MySQL or the GD library, so if you can keep the interface and feature list light it is not a difficult project. 

GIS Basics 

Geographical Information Systems (GISs) of varying complexity are becoming more common. Couriers, 
emergency services and other drivers can obtain navigation assistance. Various land information depart¬ 
ments store authoritative records with legal standing electronically. Handheld devices and computers 
provide audiences for information presented as maps. 

Depending on the degree of accuracy and detail required, this can be a specialist field working with 
expensive source data or it can be an afternoon’s work, based on freely available maps. In this application 
we will ignore most of the possible complexities and use MySQL’s OpenGIS datatypes and functions to 
deliver a simple GIS with a level of detail that might be suitable for helping customers work out which 
branch of a business is closest to them. 

MySQL version 4.1 added a partial implementation of the specification from the Open GIS Consortium 
(OGC). This defines a number of datatypes, standard data formats and operations. While there is nothing 
stoping us from storing limited geographical information in a database without specific support, having 
support built into the database gives us a number of advantages. Built in functions can do most of the 
calculation work for us, specific indexing can make our solution scalable and if we were purchasing map 
data from a third party it should be obtainable, or convertible to an Open GIS data format for importing. 
The GIS types would suit any application where the data can be represented as a collection of points, lines 
and polygons, but the most obvious application is map like data. 

With any non-trivial database application, indexing is vital. You cannot afford to have common queries 
require a full table scan to find rows or to confirm that no matching rows exist. You are doubtless familiar 
with the normal way that a database is used. Usually, the data in a database is either numeric or text 
based. Looking at a simple and common type of query like this one: 

SELECT * FROM customers WHERE firstname LIKE ’John“/ 0 ’ 

... you can see at a glance what the index should be doing with the firstname column. GIS data presents 
special challenges though. You could easily store a set of points as pairs of x and y coordinates, but how 
would you query them? 

Look at the situation in Figure 1. A number of points exist. Some are contained within an irregular 
polygon. Some are not. If these points were stored as pairs of integers, how would you write a query to 
retrieve only the points inside the polygon? If the polygon was a simple shape the query would be easier to 
write, but an index intended for more normal use would not help. Filling the WHERE clause with complex 
maths would result in a full table scan. 
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Figure 1: Imagine an SQL query to retrieve only the points that are contained inside the polygon 

Working With the Spatial Types in MySQL 

Databases that provide specific GIS functionality provide useful functions for performing geographic queries 
and indexing to make the queries tractable. Using the GIS types in MySQL we can ask common GIS 
questions like “Which of these points is contained in this polygon?” 

The most common GIS datatypes are point, line, lineString and polygon. A point represents a single 
point in space. In a map application it might represent a location that has zero width and zero length. 
A line represents a simple line between two points. In a map application it might represent a straight 
border between two states. It could also represent a straight road, if you were willing to approximate a 
road as having length but zero width. A lineString is a connected string of lines between multiple points. 
It can be used to represent more complicated line shapes than a simple line. A polygon is an enclosed two 
dimensional shape. It can be used to represent anything that needs to cover an area. It does not have to 
be a contiguous shape. There can be defined areas within the polygon that are not part of the polygon. 
This might be useful if you were defining a building as a polygon, and wanted to show that there was an 
open courtyard inside the building’s boundaries. 

All these types inherit from the abstract type Geometry and most of the built in functions can work 
with any Geometry type. Here are some of the more useful functions. 

Contains(gl,g2) 

Crosses(gl,g2) 

Disjoint(gl,g2) 

Equals(gl,g2) 

Intersects(gl,g2) 

Touches(gl,g2) 

Distance(gl,g2) 

To begin working with the geometric types, we create a table in the same way that we would for any 
other type. 

CREATE TABLE shapes 

( 

name VARCHAR(20) NOT NULL, 
shape POLYGON NOT NULL 

); 

Importantly though, we need to add a spatial index to the column that contains out geometric data 

ALTER TABLE shapes 

ADD SPATIAL INDEX(shape); 

Using the built in function geometryFromText (), you can insert data in a relatively human readable 
format. The format is called Well Known Text format or WKT. The numbers are pairs of floating point 
x and y coordinates. Note that they are embedded into a string of text to be parsed. The reason that 
the string seems to contain a redundant pair of braces is that this polygon does not contain any holes. It 
can therefore be defined by a single closed lineString in brackets. If we needed to define holes inside the 
polygon, they would each be defined by their own bracketed list of coordinates. 
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Figure 2: The relationship between our polygon and our three points. 


INSERT INTO shapes VALUES 

( 

’square’, geometryFromText( ’polygon((0 0, 20, 22, 02, 00))’ ) 

); 

A query on another table in our geometric database might look like this: 

SELECT name, asText(location) FROM points; 

... and might produce the following output: 

+ - + - + 

I name | asText(location) I 

+ - +-+ 

I middle I POINT(1 1) I 

I outside | POINT(3 2) I 

I edge | POINT(1 2) I 

+-+-+ 

Note that as the data is stored in a binary format, we need to use the built in function asText () 

whenever we are retrieving geometric data so that we get something displayable. 

The data we inserted into the shapes table (a square) and the point data being retrieved here from the 
points table is shown on a diagram in Figure 2. 

Given the relationships shown in Figure 2, you should be able to anticipate the results if we do some 
slightly more detailed queries. The question we wanted to ask earlier, “Which of these points is contained 
in this poygon?” is now easy. From the figure it is clear the points named middle and edge are contained 
in the polygon, so that is exactly what this query will return. 

SELECT points.name 

FROM shapes, points 

WHERE contains(shape, location); 


The Application 

What follows is the beginning of a GIS application. It displays a zoomable map in a web based interface. 
Depending on stored data and what part of the map the user is viewing, it will add the names of attractions 
to the displayed map in their correct locations. The end result is shown in Figure 3. 

As you can see from the screenshot, the application shows part of Australia and allows the user to 
zoom in or out. The dots and labels have been added dynamically. If more are needed you just need to 
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Figure 3: A screenshot from the GIS application 


insert them into the database. What you cannot see from a static screenshot is that zooming in or out also 
recenters the displayed portion around where you clicked, 

There are tools to do a lot of the work for us. MySQL can work out what parts of our map should be 
displayed, and which locations belong on that portion. The GD library in PHP makes loading an image, 
manipulating it and outputting it to a browser fairly painless. The hardest part might be finding a suitable 
map for your application. 

The first major design decision faced is what type of map to start from. There is detailed vector data 
available for many parts of the world. This would allow' a great deal of flexibility because it defines each 
road or other feature as a line, which the end application can render as it sees fit. It would also allow 
complete zooming flexibility as the map can be redrawn in any scale. The downsides are that the data 
tends to come at a price, and there is a great deal of work required to turn massive amounts of stored data 
into an attractive image. 

The option chosen here is to start from a raster image of a map. This involves a lot less work, as we 
already have an attractive map to display. It also involves a lot more choice. There are many commercial 
and government agencies publishing maps that might be suitable to download or scan. The major downside 
is that zooming is limited by the scale and resolution of the source material. 

In this case, the source image is a 10Mb PNG image that is approximately 3000 by 2000 pixels. While 
it would be possible to load the image for each page request and shrink and crop a section to suit, it would 
be fairly computationally intensive so we will do some preprocessing. The base image will be preshrunk 
and sliced into manageable sized tiles. The decisions were fairly arbitrary, but the tiles are 600 by 400 
pixels. They are stored at the full resolution of the base image and in five levels of shrinkage. The tiles 
overlap each other by a margin of 300 pixels. This is to ensure that somebody’s desired location is not 
on the join between two tiles and therefore hard to see. With tiles that overlap, the area of interest can 
always be close to the center. If desired, you could generate 1000s of tiles with nearly complete overlap for 
perfect centering every time. 

The tiles are created by a script called create_tiles .php. Only the most important parts of the 
application’s code are reproduced here. If you want the full source code, you can download it from 
wrww.tangledweb.com.au/presentations/. Run this script once to create the tiles and store their details in 
the database. The data we are storing looks like this: 

SELECT file, scale, asText(area) 
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FROM images 
WHERE scale = ’0.8’ 

LIMIT 1 \G 

*********************** 1, row ********************* 
file: images/scale_0.8_tiles/tile-0-0.png 
scale: 0.8 

asText(area): POLYGON((0 0,750 0,750 500,0 500,0 0)) 

1 row in set (0.00 sec) 

You can see that the filename of the tile is being stored, the scale that this tile is stored in is stored 
and the area that this tile represents on the original map is stored as a polygon. Note that all the tiles are 
600 by 400 pixels, but because this one is at 0.8 scale, it represents an area of 750 by 500 pixels on the 
original map. 

We need a coordinate system to base our universe around. We could have used a real world coordinate 
system, but sticking to the base map resolution is far easier. All the calculations are based around this. 

The first real code to look at is the p ick Image () function shown in Listing 1. 

Listing 1 — picklmageO 

function pickImage($newScale, loldScale, $x, $y, $file) 

{ 

// find the right image to display ($newFile) depending where and 
// which map the user clicked on 

list($globalX, $globalY)= translate($x, $y, $file); 

// get the possible images from the DB 
global $db; 

$query = "select x(centroid(area)) as centreX, 
yfcentroid(area)) as centreY, 
file 
from images 

where scale = $newScale and 

contains(area, geometryFromText(’point($globalX SglobalY)’))"; 

$result = $db->query($query); 
if(!$result) 

{ 

echo "cannot pick an image"; 
return false; 

> 

// work out which image has our target closest to the centre 
while($image = $result->fetch_assoc()) 

{ 

// there should be a distance function, 

// but it does not seem to be implemented in MySQL 5.0.0-alpha 

$distance = sqrt(pow($globalX - $image[’centreX’],2) + pow($globalY - $image[’centreY’] ,2)) ; 

if(!$newFileI I$minDistance>$distance) 

{ 

IminDistance = $distance; 

$newFile = $image[’file’]; 

> 

> 

return SnewFile; 

> 

The picklmageO function decides which of our tiles to use based on where the user clicked on the 
previous map and what scale we are displaying the next map at. Using the built in function contains 0 
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in our where clause we are grabbing every tile that shows the desired spot, and in PHP we are working 
out which one has it closest to the centre of the tile. That is the one we want to display. 


The locations 

The locations are stored as points. Each has a name and a location as follows: 


select name, asText(location) 
from attractions 
limit 1; 


-+- 

name 1 

asText(location) 

Melbourne I 

-+ - 

P0INT(1670 770) 


The code in Listing 2 extracts the locations from the database and renders them on our chosen map 
tile. 

Listing 2 - jpg.php 

<?php 

require(’./utilities.php’); 

$spotSize = 13; // how large to draw spots on map 

// set up font 
$fontSize = 12; 

putenv(>GDFONTPATH=C:\WINDOWS\Fonts’); 

$fontName = ’Arial’; 

// find out the size of text in that font at that size 
$bbox=ImageTTFBBox ($fontSize, 0, SfontName, ’X’); 

$textHeight = abs($bbox[7] - $bbox[l]); // how tall is it? 

// load base image 

$im = imageCreateFromPNG ($_REQUEST[’file’]); 

$red = imagecolorallocate( $im, 255, 0, 0); 

$black = imagecolorallocate( $im, 0, 0, 0); 

// get the attractions we need from the DB 

$db = new mysqli(’localhost’, ’gisuser’, ’gispass’, ’gis’); 

$query = "select name, 

x(location) as x, 
y(location) as y 
from images, attractions 
where file = ’{$_REQUEST[’file’]}’ and 
contains(area, location)"; 

$result = $db->query($query); 
if (!$result) 

echo "DB Error: Iquery <br>".$db->error; 
exit; 

> 

// add each attraction to the map 

while($attraction = $result->fetch_assoc()) 

{ 

list($x, $y) = translate($attraction[’x’], $attraction[’y’], $_REQUEST[’file’], true); 
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//draw the ellipse 

imagefilledellipse ($im, $x, $y, $spotSize, $spotSize, $red); 
imageellipse ($im, $x, $y, $spotSize, $spotSize, $black); 


// add label 
imageTTFText 

} 


($im, $fontSize, 0, $x + 2 + $spotSize/2, $y+$textHeight/2+l, 
$black, $fontName, $attraction[’name’]); 


// finalise the image 

header (’Content-type: image/jpg’); 

header(’Content-Disposition: inline; filename="map.jpg"’); 

imageJPEG ($im, ’’, 75); // a PNG would be sharper but bigger 

imageDestroy ($im); 


The GD library functions allow us to load an existing image (in this case one of our PNG tiles), add to 
it and then write it out. For each location we draw a red circle, draw a black outline for the circle, then 
add the text from the database as a label. Finally, we send the right headers to the browser to make sure 
this gets interpreted as an image and dump the image to the browser. 

We have opted to store the images as PNGs but send the final result to the user as a JPEG. For this sort 
of tonal image, JPEG compression will be much smaller. It does reduce sharpness and introduce artifacts 
however, so we do not want to be recompressing it as a JPEG multiple times. 


Conclusion 

From this functional beginning, you could extend this application in many ways. An obvious addition 
would be scrolling controls in the user interface. You might also like to investigate ways of overcoming 
problems of labels that overlap or run off the edge of the tile. If you really want a challenge, try combining 
multiple maps for greater zoom range. Note however that maps drawn in different projections require a 
great deal of translation to work between. 
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Introduction 

Security of PHP web applications has been getting a lot of press lately due to some vulnerabilities in 
well well-known and widely widely-used applications. For example, the XML_RPC module from PEAR 
was recently discovered [1] to have a remote code execution vulnerability. This module is used widely in 
applications such as WordPress [2| and Drupal [3], both of which which have a large install base in the 
user community. 

When referring to PHP Security, what I really mean is the security of web applications that you might 
build, not the security of the language itself. Security issues that arise in the language itself should be 
managed by keeping up to date with patches and security advisories, and this is obviously an essential 
step. 

Protecting a web application against malicious users is a vital task. As a developer you have a profes¬ 
sional ethical responsibility to try and write secure code. Learning how to write secure code is not a topic 
that can be completely covered in a short paper like this. The goal here is to hit some important points 
you should be aware of while developing code in PHP. 


Basic Principles 

There are two basic principles you can follow which will cover a lot of eventualities. 

1. Trust no one. Any data coming from outside your application is not to be trusted. This can be 
data coming from the end user, from other servers, from web services, from an external database. 

The basic approach here is to think about each piece of data that you deal with in your application: 
Where does it come from? What could be done to it to try to make it dangerous to your application? 
What can you do to protect against it? 

Basic protection against tainted data comes from two practices: filtering all input, and escaping all 
output. 

Input is any data that didn’t originate directly from you. That can be from any of those sources 
listed above. Bear in mind that some input sources are not obvious: cookie data, for example, comes 
from the user’s machine, and can be altered easily by the user. You can filter input data using a 
whitelisting approach: don’t accept any data that doesn’t match the expected shape. 

Output is the opposite: data your application is presenting to the world. Escaping output is done to 
avoid any unintended effects of your output upon the recipient. For example, if sending output to a 
database, you want to make sure that only the queries you wrote are executed, with no additional 
“injected” SQL from included user data being executed. 

We will look at examples of both of these practices and why they are important later in this paper. 

2. Keep yourself and your install up to date. 

Educate yourself as to the security problems that can arise and code accordingly. New exploits are 
invented every day. Track security advisories and upgrade server software, PHP, component code, 
and your own code when required. 

Next, I’ll look at some specific security issues. 
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register _globals 

Prior to PHP 4.2.0, many PHP users didn’t know that the register-globals configuration directive 
existed. For lots of people, the first they heard of it was when they upgraded PHP and their code no longer 
worked. At this version, the default setting for this configuration directive was changed from on to off. 
This had the effect that instead of accessing input variables as, for example, $my-form-var, they now had 
to be accessed as S-GET/’niy-form-var’], $-POST[’my-form-var’], or $-REQUEST[’my-.form-var’]. 

Why was this change made? It was done to try to protect against the poor programming practice of 
not making sure all variables are initialized to an appropriate value. A classic error of this type looks like 
this: 

<?php 

if ($user==’admin’ && $password ==’secret’) { 

$admin = true; 

} 

if ($admin) { 

// allow admin stuff 

> 

?> 

If register-globals is on, then a malicious user can load the page via, for example: 

http://example.com/yourscript.php?admin=true 

Of course, having register_globals off won’t fix everything. You still need to write good code, and 
making sure variables are initialized is one important way to do this. The first line of the script above 
should set $admin to false. 

Some code uses the extract () function to convert all variables in a superglobaln array to their short 
form automatically. If you choose to do this - or to switch register_globals on - you need to be aware 
of the implications for variable injection, and be even more aware of the need to initialize all variables. 

xss 

XSS stands, oddly enough, for Cross Site Scripting. (The acronym CSS was already taken). It is a slightly 
confusing name, but what it refers to is an attack by a malicious user where they enter some data to your 
web application that includes a client- side script (generally JavaScript). If you output this data to a web 
page without filtering it, this script will be executed. 

For example, consider a nave guestbook or forum implementation that includes in part some code like 
this: 

<?php 

echo $raw_user_postings; 

?> 


Whatever JavaScript users may have entered in their postings is sent down to the browser and echoed 
at the client side. You might be saying, “So what? What can I do with JavaScript?” Here are some ideas: 

• Pop up annoying new windows advertising your porn site. 

• Steal the user’s cookies. 

• Redirect them to another website. 

• Even just with HTML: show them a form that looks “official” that leads to another website. “Your 
session has expired, please log in again here.” 

Fortunately this particular attack is relatively easy to protect against. If you follow the good basic 
principle of escaping output, this problem should never come up for your users. The PHP function rec¬ 
ommended for this purpose is htmlentities() which will convert all characters that have HTML character 
entities into those entities. For example, <, the start of any HTML tag, will be converted to felt; So our 
code above becomes: 

<?php 

echo htmlentities($raw_user.postings); 
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SQL and Command Injection 

In this section I will cover two very similar attacks: SQL injection and command injection. These attacks 
are functionally similar to cross site scripting in that the end result is code entered by a malicious user 
being executed. 

In SQL injection, a user “injects” SQL into their input in such a way as to have it executed on your 
system. For example, imagine that you have a form designed for users to log in, and we have pulled out 
the username and password into $username and $password respectively. We then run a query like: 

select * from user where username=’$username’ and password=’$password’ 

Imagine further that instead of typing in a username, the user typed in 

"admin’ 

What happens when this data is inserted into the query? 

select * from user where username=’admin’ —’ and password=’$password’ 

Everything after the — has been commented out. The net effect of this is that it is likely the user 
has just logged in as admin, without needing to know any passwords. (This example, and several chilling 
others, are illustrated right there in the PHP Manual [4].) 

The solution to this is to escape output in a way that is appropriate for the destination of that output. 
When you send output to the browser, to avoid XSS, you escape the output with htmlentities (). For a 
database, you should use whatever appropriate function PHP has as part of the database extension for your 
database. For MySQL, for example, you should use mysql_real_escape_string(). If no such function 
exists for your database, you can use the addslashesO function, or roll your own appropriate one. 

You might be thinking “But doesn’t magic quotes take care of that for me?” In the same way that you 
can’t assume register_globals will be on (or off for that matter), you can’t rely on magic quotes being 
enabled on any given target system. 

You can achieve the safety in another way by using prepared statements and binding parameters. 
Prepared statements are a database mechanism where you send a query with placeholders - like a template 
query - to the database, and then send the parameters separately. This functionality is available in most 
of the popular web databases, including MySQL, PostgreSQL, and Oracle, and is also available via the 
PDO database access extension. Using prepared statements also has the advantage that it will generally 
speed up query execution, so this is a very good option. 

Command injection is the same basic attack but applied when you are outputting user data to a system 
command using a function like execO or system!). For this application, you can escape user data with 
either the escapeshellcmdO or escapeshellargsO function, depending on exactly what you are doing. 


Exposed source code 

Exposed source code occurs when the PHP engine doesn’t execute your code. Typically, this occurs when a 
programmer writes PHP libraries and saves in the web document tree with an extension that the web server 
does not recognize to be a PHP file such as .inc. This source code may contain usernames, passwords, or 
other information that you do not want made public. 

The basic solutions to this are either to name all files with a .php extension, or to store libraries outside 
the web document root. 


Session security 

There are a number of issues to do with session security. The two most commonly discussed ones are 
session fixation and session hijacking. 

Session fixation occurs when a user arrives at a website with a pre-fixed session id. For example, HTML 
email arrives from a dubious “friend” with a link embedded in it - or you visit a webpage with such a link 
embedded in it. The link goes somewhere like: 
http : //example . com/order . php?PHPSEHRTn= nnnnnnnrmT-mnn 

An innocent user follows the link and continues to surf inside the session that belongs to a malicious 
user, perhaps logging into their own account and failing to log out, giving access to their personal data to 
the attacker. 
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Session hijacking has a similar goal, which is, rather than providing a session id upfront, to obtain the 
session id of another user via nefarious means. 

To prevent session fixation, you can use PIIP’s built in session_regenerate JLd() to change the session 
identifier. You should do this whenever a user logs in or out, or if the level of privilege changes. This way, 
although the attacker knows the original session ID they provided, they do not know the new one and will 
not have access to the higher privilege level. 

Session hijacking through other means is slightly harder for the attacker to execute. Session IDs are 
long, random, unique, and difficult to guess. You can protect them further by always using SSL when 
sessions are used. 

Another technique that protects against both of these attacks is to use the configuration directive 
session.use_only.cookies. This forces PHP to pass the session identifier in a cookie. (It will also make 
your session control unusable by users with cookies disabled, so there is a small tradeoff.) 

CSRF 

CSRF stands for Cross Site Request Forgeries, another attack with a complicated name. A CSRF is a 
request for a page that looks as though it was initiated by a site’s trusted user, but wasn’t. There are 
many different variations on this type of attack. One example commonly cited is to embed images in a 
malicious page that have a link to a PHP script as the SRC attribute, with GET parameters attached. 
When the user’s browser tries to load the image, a request for that page will be issued, along with any 
cookies the user may have for that site, such as session cookies identifying the user as being valid or logged 
in. The user just sees a broken image, but something sinister has occurred without them even realizing it. 
Consider for example: 


<img src=’http://example.com/click_to_buy.php?item=12345’> 

Our unsuspecting user may have just purchased an item that they didn’t want. 

There are several approaches to defend against this. You can of course avoid this kind of solution 
architecture, including using GET parameters for pages at all. When using forms, to avoid CSRF attacks, 
you can generate a single time token that identifies this unique form for this unique user, transmit it as 
part of the form, and save it to the user’s session. Tokens can be easily generated using PIIP’s md5() or 
shalO functions. You can then check validity of the token with code similar to the following: 

// check for form token to thwart CSRF 
if ((isset($_POST[’token_from_form’]) && isset($_SESSION[’token’])) 

II !isset($_P0ST[’token_from_form’])) { 
if(($_SESSI0N[’token’] != $_POST[’token_from_form’]) 

II !isset($_P0ST[’token_from_form’])) { 

// CSRF attack 

echo ’There was a problem with your form submission. Please try again’; 
exit; 

> 

> 

Preventing other security problems 

This article is only a short introduction to common security attacks in PHP, and prevention methods. 
There are many others, and every day, a bored 14 year old geek comes up with a new attack. What can 
you do to deal with other types of attack? To write good code you need to keep yourself up to date, and 
this means reading advisories and news, and applying patches as they are issued. 

To help you write good code, you can go into your php.ini file and turn error reporting up to E_ALL & 
EJ3TRICT on your development box. This will advise you about uninitialised variables and other coding 
problems. You can also undertake peer review of your code. This can be done between developers in an 
organization, or by hiring a third party security expert to perform a security audit on your code. 


Conclusion and Resources 

This brief article is only an introduction to the topic, and I would encourage all PHP developers to read 
further. Some really useful materials can be found in the PHP manual security section [5] and on the 
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website of the PHP Security Consortium [6]. 

It can be both embarrassing and expensive to have security flaws in your PHP application. While it 
can be difficult to completely harden web applications, especially when the concepts are new, the practices 
and resources mentioned in this paper will help start you on the path to safer code. 
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Foreword 

The purpose of the paper is to assist those who may find themselves responsible for an enterprise printer 
fleet with little previous experience. The author having been in the position of implementing an enterprise 
print solution with little understanding of the consequences of some decisions made during the design 
phase, hopes that this paper will provide a better understanding for others. Whilst information on why 
having a strategy is available from various reports and studies, and is briefly summarized here, suggestions 
when designing an implementation are difficult to locate. The information contained in this paper is based 
from the author’s personal experience of supporting printing issues over the last 5 years, as well as advice 
from those who have been involved in this topic for many more years. 

Why have an Enterprise Print Solution? 

Before answering ‘why have an enterprise solution’, let us define what is meant by Enterprise Print Solution. 
You will note that this paper uses the term solution rather than the more common reference of strategy. The 
reason for this is that a solution is a method in order to resolve a problem, and in the enterprise, unmanaged 
output is a problem. A problem that is not normally considered until its impact to the enterprise or an 
individual business unit, has hit a critical level. Therefore we are looking at enterprise print solutions as 
ways to manage the delivery and support of output generated by the enterprise in a cost effective and 
purposeful way. Thus this paper defines an enterprise print solution as involving more than just having a 
naming standard for printers. It involves having policies and procedures for purchasing, usage, support, 
accounting and software. 

Within an enterprise there are two views as to why investing in a long term solution is a good thing. 
The first is from the business perspective. Enough studies about costs exist from various analysts that 
show a saving can be made by enterprises reviewing and implementing output management solutions. Let’s 
face the fact that costs are what any organization is always trying to reduce. Conclusions from studies have 
shown that enterprises are spending between 1 and 3 percent of revenue on producing hardcopy output 
with some analysts estimating the total cost of enterprise printing being as high as 15 percent of enterprise 
revenue 1 . This higher percentage includes the indirect costs as well as those of toner, paper etc. 

The second view point is from the Systems/Application/Network Administrators. It is the existence of 
these high indirect costs that supports the case of why the various administrators should also care about 
implementing an output management solution. Here estimates of 30 percent and higher of helpdesk calls 
being printer related exist. Whilst a number of these are able to be resolved by the helpdesk a significant 
number still get assigned to higher levels of support. Through implementing an enterprise print solution, 
apart from reducing the number of calls to helpdesk staff in the first place, a further reduction of calls 
being assigned through to higher level support can be achieved. This means the Administrators can better 
use their time on more purposeful tasks. It can also be proposed that with fewer helpdesk calls end users 
are also gaining more time for productive work vs chasing up printer problems. 

So from experience and studies enterprise printing costs include: 

• Hardware 

1 Lexmark Printing Solutions and Services Division (PDF) 
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• Consumables 

• Maintenance 

• Administration/Support 

• End user time 

To some extent these can all be directly or indirectly reduced through the implementation of policy 
that is supported at all levels of the organization. Some suggestions on policy are: 

• Limiting of makes and models within an enterprise. 

• Devices to be tested with existing infrastructure and applications 

• prior to approval of purchasing within the enterprise. 

• Clearly defining requirements for new printer types. 

• Guidelines for when certain types of devices may be purchased. 

• Limiting output that can be printed prior to review or requires manual release. 

Some enterprises will most likely have the first in place already due to centralized purchasing or like. 
The second and third can provide savings in support costs as this can reduce the time support need to 
spend trying to get applications to work with a device or a device to work on the network. In some instances 
I have seen a second device purchased and placed beside the original as the original could not be made to 
work with all enterprise applications. The fourth dot point is suggested to prevent departmental printers 
being purchased for groups of 4 people or a desktop laser being purchased and placed on a network because 
the user would need to walk 5 meters to collect their output. The fifth suggestion is in order to reduce the 
amount of output a business generates. Despite the ideal of the paperless office, industry figures indicate 
that distributed printing is growing and by a rate by about 20 percent a year. 

Whilst implementing policies may help with costs it will not deliver the maximum benefit without also 
implementing an enterprise output management software package. By implementing a commercial package 
full advantage can be taken of an enterprises policies and provide ability to develop additional policies in 
areas of cost recovery. 

Commercial solutions can provide: 

• ERP interfaces 

• Accounting 

• Datastream conversions 

• Simplified management 

• Security 

• Support cost reduction 

• Alternate delivery mechanism 

It is through these features that costs can be saved to an enterprise. At the most basic levels experience 
shows that by merely installing an enterprise grade software suit to handle printing can reduce the amount 
of time spent in supporting “printing”, and availability of devices increase. Native spool services can 
not compete with these commercial products. These products have been developed by companies for the 
express purpose of overcoming the inadequacies in the native systems. 

So the enterprise has seen that costs can be reduced and an output management solution purchased - 
now how do we implement and what pitfalls await. 

Issues such as the method of connecting to printers, the naming of printers, security consideration and 
conversion requirements can all impact on the future use and support of printing in the enterprise. The 
following topics will review some of these and the impacts they have. 
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Interconnections 

The way in which output is delivered and routed around our print network impacts on what capabilities 
we can expect to be available. Some areas of cost that can be impacted on by our selection of connection 
methods are: 

• Consumables 

• End user time 

• Support time 

Below details some information on the more common current enterprise interconnection methods utilized 
today. 

LPR/LPD 

This is the most common protocol of delivering output from a spooler to printer on a TCPIP network. 
RFC 1179 provides technical information regarding this protocol. For modern enterprise environments this 
protocol should only be used when the receiving printer cannot support either of the following connection 
methods. Another point to be aware of is that even though LPR/LPD has been around for many years, 
it is the experience of this author that not all implementations are by default compatible. Configuration 
options need to be reviewed to sometimes correct minor issues. This can also mean reviewing printer 
firmware for issues when everything else appears correct. 

LPR/LPD is used today by clients delivering output to print servers along with print servers delivering 
output to print devices. 

Benefits: 

• Nearly all TCPIP printers support this protocol, this includes network attached inkjets as well as 
lasers. 

• Utilizes well known ports. This can be a requirement from network security. 

Disadvantages: 

• Automatic error recovery is not supported. This means if a job fails part way through, barring 
manual intervention, the whole job needs to be reprinted. 

• Unable to provide assured printing of output 

Direct Sockets 

Several terms exist to describe this process as there is no single standard for implementation. The use of 
the IIP standard of using port 9100 on the printer however could be said to be the de facto standard as 
several vendors use this by default. Other vendors allow this port to be set through configuration within 
the printer and some very few use another port that cannot be changed. (Hint: where some vendors allow 
this port to be set it is the value you specify in the printer +1.) This method works by having the incoming 
TCP connection open directly to the print engine. This is a bi-directional connection back to the sending 
software allowing error messages and other information to pass along the communication stream. This also 
allows for the use of Printer Job Language (PJL) commands. 

More so than with LPR/LPD, testing of devices should be required prior to purchase. Whilst most 
modern network laser printers support this connection method other factors come into play. In particular 
you will occasionally find that a printer will not support bi-directional communication on the socket con¬ 
nection and/or does not implement or correctly implement all the necessary commands required by your 
software to make use of the bi-directional channel. Also other types of printers may not offer this support 
at all, example network attached inkjets. 

Direct sockets in general are used only for delivering output from print servers to print devices. This 
author has not seen an instance where a direct socket connection was used for delivering a print stream 
from a client to a print server. As it is designed to provide bi-directional communications, implementations 
that use direct sockets can provide enhanced print control features. These features can include auto error 
recovery and assured printing, 

Benefits: 

• Can allow for automatic error recovery 
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• Can allow for provision of assured printing 
Disadvantages: 

• Not as widely supported as LPR/LPD 

• No single standard 

Internet Printing Protocol (IPP) 

The first RFC written for IPP was RFC 2565. This has since been superseded and numerous additional 
RFC’s written enhancing and expanding IPP. IPP is becoming the most likely connection method from a 
client to a print server, be that a software server acting as an IPP gateway or an IPP server embedded 
directly in a printer. The benefits of IPP are constrained by the implementation generally found in the 
server. Not all servers support the full capabilities provided for in the IPP RFC’s. At this stage few 
enterprise applications support IPP as a client connection method making this primarily a desktop client 
connection protocol. 

Depending on implementation, IPP may enable information about print jobs to be sent back to clients. 
It may also enable clients to query hardware configurations of devices. 

Benefits: 

• Provides increased benefits to desktop clients over LPR. 

Disadvantages: 

• Not natively supported by most enterprise applications 

Proprietary Protocols 

Some companies that have developed enterprise print solutions have also developed proprietary protocols. 
These protocols are normally used for either communicating between server components enabling advanced 
features such as encryption and compression or for use by client systems running the provided client 
software. Clients that use the proprietary protocol gain benefits like the encryption and compression as 
well as other advanced capabilities such as provision for additional parameters. These clients are normally 
directed to work with enterprise software such as SAP and Peoplesoft. Use of these on normal desktop 
systems whilst sometimes possible is not normally practical. 

Benefits: 

• Provides advanced capabilities such as encryption 

• Can utilize ERP API’s for advanced features. 

Disadvantages: 

• Vendor dependant support 

Review 

When selecting the method of communication from the ‘print server’ to the printer it is the suggestion of 
this author to select the Direct Sockets method. The advantages and benefits this method provides when 
using an enterprise print software solution outweigh those times when a device will fail to support this. 
When testing new devices the ability of the device to support this method in the sites native configuration 
should be used as a testing base. This will assist in the later topics of printer management. For those times 
when an existing device is already on the network and cannot be readily replaced or a device that does not 
support this method, but must be allowed, then LPR/LPD should be considered the fallback. Managing 
these situations then becomes the main complexity and processes should be put in place for this. 

When communicating from applications to the print server(s) there are two scenarios: 

1. ERP/server application 

2. Desktop applications 

For scenario one the suggestion is to use a proprietary client if one is supplied with the print server 
software. This will allow for maximum return of investment. For scenario two it is suggested to use IPP. 
This allows for an easier management whilst still providing for increased information to the client. 
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Management of Printers 

This topic like the next is very organization dependant. The specifics that may work for one organizations 
structure may not work for another. Likewise the design used for one brand of software may not be the best 
design for another. This second point should be remembered when conducting trials against an existing 
solution. If a product is measured against an existing structure this may not return the best results for the 
product under trial. As a result this paper will not look to go into specifics but try to provide ideas and 
concepts that can be considered when implementing a solution that may not be fully considered otherwise. 

When looking to implement an enterprise print solution a review of how that solution is to be managed 
should be one of the first things done. This will enable a design that will meet the current organizations 
requirements and hopefully allow for changes and growth in a controlled manner. The primary goal of 
the design is to improve the printing infrastructure of the organization. During the process both the 
administrative and technical processes will need to be developed in a joint manner. Developing either in 
isolation will lead to further problems in the future. The need for this is that to address some issues a 
technological solution can be implemented, for others an administrative. 

So some design considerations at this stage are: 

• Naming standards 

• Physical printer referencing, by DNS or IP address 

• Connection methods 

• Management interfaces 

• ‘One Offs’ 

• Responsibility levels 

• Documented procedures 

• Escalation procedures 

Administrative 

In most large organizations the responsibility of administering printers normally involves administrators 
from different platform groups. One suggestion here is to create a virtual unit that combines the relevant 
people from these groups to work on the design and on going administration. This creates a greater under¬ 
standing of the overall enterprise printing requirements and leads to a more cohesive implementation that 
can reduce the amount of duplicated effort. It also allows for an increase in cooperation and understanding 
between these platforms. An example here is that normally one of these groups will be responsible for 
the IP addressing and DNS naming of physical devices. This means that the other groups will have a 
dependency on how that group manages changes to either IP addresses or DNS names. 

Having a virtual printer administrative group can also assist in potentially simplifying processes for 
lower level support groups. Apart from potentially simplified diagnostic processes, due to a greater under¬ 
standing of the overall printing architecture, it becomes possible for these lower level groups to be given 
increased capabilities allowing for them to resolve issues in an improved timeframe. Another component 
that allows for this is security. Most if not all commercial products allow for the management capabilities 
of either devices and/or print jobs to be controlled to ensure that systems cannot be adversely affected by 
inappropriate actions by untrained staff. 

It is also vital to have the infrastructure documented. This documentation should cover all the dot 
points above as well as provide a list of approved devices and testing processes. One of the most important 
documents is the exceptions document. This is a document that should cover devices that do not meet 
the standards criteria, however do need to be put into the enterprise. Allowing these devices may mean an 
additional internal charge, a special naming convention, a custom process for that device or a combination 
of options. A register of these needs to be kept with any relevant changes to the normal documentation 
noted. All support staff responsible for printer problems then need to have access and be aware of this 
register. It is these devices that can create the most amount of work. This is primarily due to another 
support person not being aware this device is an exception and needs to follow modified procedures when 
making modifications. This can then lead to more complex problems that can take longer to resolve and 
clean up. 

To highlight the two key administrative components of efficient management of printers are communi¬ 
cation and documentation. 
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Technical 

In today’s enterprise environment TCP/IP will generally be used to communicate from servers to printers. 
One decision that needs to be made is will they use a DNS name or a direct IP address. Both situations 
have good and bad points. The printer group need to work out which is best for their environment. Things 
to consider though are how the DNS names are generated. If they use the make or model as part of the 
DNS and the printer is changed, causing a change in the name, then the management system needs to be 
updated. This may or may not be a big issue depending on how many printers are managed and how often 
they change. The same goes for names that have location or office identifiers in them. The flip side is that 
these names are generally easier to remember for all support staff rather than IP addressing and can be 
used in creating a naming convention for the printer definitions in the management system. Another goal 
when dealing with printer naming is to try and make the printer name the same across all the systems. 
This makes support easier for all involved and staff do not waste time trying to identify the printer the 
customer is calling about. 

A big problem in implementing any form of new naming is integration into system applications. Some¬ 
times changing this is not possible and the old naming system needs to be integrated into the new print 
management solution. Work generated from printer name changes is an on going task and cost. One of the 
best methods to reduce this is through a simple and efficient management interface that when provided 
with clear procedures enables this process to be provided to the lowest possible support point. 

Management interfaces need to be reviewed on a couple of layers. 

1. What options are available 

2. What is currently using the existing system and can the new system replace this functionality. 

3. Ability to adapt to changes 

4. Record storage - flat file or database 

A GUI/Web interface is a must when providing lower level support staff with management and diag¬ 
nostic responsibilities. It can also make things easier for administrators when dealing with fault issues. 
Other interfaces, in particular a command line interface, can make performing major updates/changes far 
easier to script. 

The administrators also need to ensure application developers in the organization have not used the 
existing systems to integrate into their own applications. If this has happened then a determination needs 
to be made if the functionality is provided in the new interfaces that the developer can recode to use or if 
it is possible to maintain parts of the old management system until the applications using that function 
are replaced/updated. Not maintaining the old system purely for application integration can be a costly 
support exercise and minimize the benefits available of the new management systems. These costs should 
be reviewed against the cost of modifying the existing applications. 

Various people think that how the record containing printer definition information is stored is a signifi¬ 
cant issue. Assuming the necessary interfaces are provided that give access to those records then this paper 
does not consider it to be significant. If however an API or command line interface is not provided then 
administrator scripting or custom interface programming can be severely limited if a proprietary database 
is used by the application. This scripting can be needed when global changes are needed to be made. 

As mentioned in the last paragraph some management suites do provide API’s or other means of writing 
custom interfaces. This is a two-edged sword. On the one hand it can provide for integration into existing 
internal management tools but this then means that maintenance of these tools needs to be performed. 
Should additional features or changes occur then development work needs to be performed. The suggestion 
here is that if a professional level development has been performed including full documentation and can be 
maintained by any developer then the benefits to the organization may out weigh the cost of this process. 
The situation to avoid is having the administrators develop their own “quick” apps that the business may 
come to rely on that no one else can readily maintain. Should this person leave and changes are required 
this may then require significant amounts of resources to correct. ‘If the provided interfaces are sufficient 
- use them’ 

A last point on the interface is the ability of the interface to readily process the “One-Off” printer 
requirements. If a management system has been put into place that requires predefined definitions to add 
a printer, how will this work with a printer that is unique to the system. Will additional definitions need 
to be created for this printer that will never be used again? Having the ability to perform a single manual 
definition can be time saving and should not be a problem as administratively this printer should already 
be noted as an exception along with it’s business case. 
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Management of output 

Apart from managing printers, an output management product should also be able to manage the datas- 
treams that are passed through it. This management may be the provision of accounting records on the 
data, converting the data into another format and/or holding the job for review. It could also involve 
performing some form of logic processing based on the attributes of the data to redirect to another printer 
based on cost. The capabilities are dependant on the product. Some capabilities to look for are: 

• Datastream conversion 

• Security 

• Retention 

• Logical processing 

• Accounting 

Datastream Conversion 

This allows for one type of datastream to be sent to the spool and then be converted to another prior to 
being sent to the printer. Why? Most conversions are from some type of enterprise format like OTF/GOF 
(SAP format) or AFP (IBM format) to a more common PCL, Postscript or PDF. PCL and Postscript can 
be handled by nearly all laser printers and PDF can be sent electronically or viewed online. An example is 
a conversion from OTF to PCL. This allows barcodes to be printed from an SAP/R3 environment to any 
PCL capable printer without the need for additional hardware. 

Security &: Retention 

The ability to have data held prior to printing or be retained after printing allows for additional cost 
savings and benefits. The need for security on these held spool files though now needs to be considered. 
Can these files be viewed online? If so then who can view them and control them? Can the user select a 
subset of the file to be released? Three benefits of retaining a file after it is printed are: 

• Application processing resources are not spent a second time 

• If the data is dynamic and may change the report can be reprinted with the original data 

• If the report is printed from a central system and transferred across a low bandwidth WAN to a print 
server before going to the printer. Here a reprint will not require the data to be sent across the WAN 
a second time. 

The issue to be monitored with retention is the retention time. If files are held for too long these can 
impact performance if not enough disk space exists for the spool. Files should have an expiry data that 
the system will use to automatically remove these files with. 

Logical Processing 

Different products call this ability different things and implement it in different ways. What the author 
means is the ability for the software product to be able to perform some action based on the attributes of 
the incoming print job. An example of this might be to redirect the output to another printer based on 
the number of pages. Someone sends a large print job to a small network laser. The product automatically 
reroutes the job to a larger departmental printer. This action is configured by the group responsible for 
printer management. Some products allow for custom scripts to be written and provide entry points or 
triggers to drive the scripts based on events that occur within the print environment. Once again should 
these be utilized then documentation of these scripts is a must. 

Accounting 

In today’s enterprise environments of cost cutting/recovery and drives on improving efficiency, the ability 
to track output is a must. Accounting can provide a wealth of information. This information can be used 
for other reasons in addition to cost management. It can also allow for administrators to track resource 
utilization within the print infrastructure and help with diagnostics of printing issues. 



290 


DESIGNING AN ENTERPRISE PRINT SOLUTION 


Turning accounting on in a package is pointless though if the information is not reviewed. Some products 
allow the accounting records to be customized. This is useful so that the metrics tracked can be set to 
those required by all parties who have an interest in this information. Here the print administrators need 
to make people aware this information is available and then publish this in a format that is easy to read. 
Records kept over time will also allow for trends to be tracked and with good planning allow for further 
cost reductions. 

Whilst output management systems can track some information about the print jobs sent through them 
by default, to really gain the benefit and to track trends the system needs to be designed to have all the 
location and model types included in the printer definitions. Fields or parameters are normally available in 
printer definitions to store this type of information. This information can then be used for trend analysis 
in addition to assisting helpdesk staff. Trend analysis can provide benefits not only to IT support staff 
but also to other business units involved in supply chain management. In large organizations some form of 
centralized purchasing will normally already be in place. By analyzing accounting information over time 
the organization can predict when consumables for printers will be most in need and can potential gain 
purchasing power with his knowledge. 

When using the right tools trend analysis is not hard nor is it time consuming. The benefits to all areas 
of the organization however can be tangible. 


Alternatives to printing output 

The “paperless” office has been talked about for years but has never eventuated. Whilst not able to 
completely provide the full answer the technology does exist to enable a paper reduced office. Two things 
need to be understood. People like to print and it will require management to support policies that require 
users to view documents in an electronic format. The second is that currently if the user has a local 
USB/Parallel printer you cannot track nor easily prevent them from printing electronic documents. 

A caveat regarding this topic is that certain documents are required in hardcopy format by law. A 
reduction can still be achieved with these documents by reducing the waste of draft prints, the same as 
with normal documents. 

Two common methods of paper reduction are: 

• Using a combination of datastream conversions and held output, policies can be implemented that 
require users to view their documents via their web browser and then only select those pages they 
need to print, or not print at all. This is mostly of benefit with reports from larger enterprise systems. 
Reports from desktops are still likely to be printed in full. 

• Another option is to have those reports that would normally be printed emailed to the required 
parties. This can also make use of datastream conversions. This can provide additional savings in 
postage if those people are normally external to the company. 

Another benefit of commercial solutions is they normally make the ability to provide legacy systems 
with the ability to provide electronic output painlessly. In some cases no changes to application processes 
are needed. 

To reiterate the biggest problem to be faced by organizations trying to reduce paper printed is the end 
user/business groups themselves. The best way to improve this is through involvement of these groups. 
By addressing the concerns and explaining the drivers of the changes will ensure the best result. Another 
key is to highlight the benefits the user can gain. This benefit will vary depending on user/business group. 
The key for the administrators is to find this benefit during the discussions and then highlight that benefit. 


Conclusion 

Most organizations have print environments that have evolved over time with little concern to the overall 
enterprise. Most organizations do not even have a clear picture of their existing infrastructure or of the 
current cost of printing to the organization. Cost savings to the enterprise along with time savings to 
support staff and end users are achievable. Organizations need to review their printing infrastructure and 
realize there are better ways of printing. The areas to review are: 

• Management of printers 

• Management of output 


• Application interoperability 



CONCLUSION 


• Cost recovery 

• Documentation of policies and procedures 






andriva Linux 


1 1 L * 


Corporate Seryer 


Server Moo 


INTRODUCES 


Corporate Server 3 

/Rock Solid & Secure 
/ Easy to configure 
/ Five year support cycle 
/ LSB 2 Certified 

/ Samba 3 ♦ Apache 2 ♦ Kernel 2.6 
/ LDAP NIS Windows® Authentication 
/ USB 4 - IEEE1394 Support 


Corporate Desktop 3 

/ User Friendly 

/ OpenOffice ♦ KDE 4 - Kernel 2.6 
/ Mozilla ♦ Evolution 4- Acrobat® 
/ FlashPlayer™ 4 - RealPlayer™ 

/ Crossover Office Standard Demo 
/Connect to Citrix Server 
/ USB 4 - IEEE1394 Support 
/ Five year support cycle 





MandLin Sales Ptu. Ltd 

ABN 54 110 903 118 ^ 


Australian and New Zealand Distributors of Mandriva Linux 


PO Box 69 

Annerley, Queensland 4 I 03 
Australia 


Ph: +6 I 7 3342 4253 
Fax: +6 I 7 3848 3429 
sales@mandlinsales.com.au 












